Firebird’s Lock Manager - Firebird

In Superserver, the Lock Manager can be thought of as a separate “control center” that transactions negotiate with to acquire the right to proceed with requests. The Lock Manager comprises a chunk of memory region and some request -handling routines. Its memory is tabulated into various blocks: lock blocks, which refer to resources; request blocks, which represent requests for a lock on a resource; owner blocks, which represent transactions and other objects that request locks; and history blocks. Its routines are responsible for accepting and managing requests by owners for locks on resources, for allocating the locks, and for releasing them. Superserver also manages “latches” for coordinating changes by concurrent transactions.

Classic is simpler: owners queue to get control of the lock table so that each process’s lock management code can queue, grant, and release locks for its owners.

Lock States

Every operating system offers some kind of free/busy mechanism for synchronizing resource events. Because Firebird needs a multi-state control mechanism, it implements its own seven-state lock management system. Figure illustrates how the locking levels are decided.

Firebird internal lock states

• 0 is free.
• 1 is a null lock, which indicates an interest in the object but no restrictions on others’ use of it. Acquiring a null lock allows a transaction to read the lock data.
• 2 is a shared read, which allows writers. Shared read is the normal mode for table locking until the transaction changes some part of the table.
• 3 is a protected read, which allows other readers, but not writers. Protected read is the normal mode for locking a database page that is in cache and has not been modified.
• 4 is a shared write, the other normal table locking mode. Shared write is compatible with shared read and other shared writers, but not with either protected mode.
• 5 is a protected write, which allows shared readers and null locks, and nothing else. Protected write is used for consistency mode (table stability) and for locking a database so normal users cannot access it.
• 6 is exclusive and is used for internal structures when concurrent access could interfere with an update or cause the second transaction to read incomplete data.

The Lock Table

The Lock Manager maintains a lock table to coordinate resource sharing among the client threads. The information stored here can be useful when trying to correct deadlock situations, for example:

• All the locks currently in the system, with their states
• Global header statistics such as the size of the lock table, the number of free locks, the number of deadlocks, and so on
• Process flags, indicating such things as whether the lock has been granted or is waiting Locks are stored in series, each series identified by a number, according to the type of resource locked.

Use of Null Locks

Transactions starting up use the lock table as a bulletin board. To avoid garbage collecting record versions that another transaction needs, each transaction needs to know the identity of the oldest action any other transaction has seen. Here is how it is done:

1. When it starts, a transaction stores the ID of the oldest transaction still running into the data portion of its transaction lock.
2. It then gets null locks on all concurrent transactions. When each lock is acquired, the contents of its data portion are returned.

The new transaction checks the lock of each existing transaction to discover the identifier of the oldest transaction that any active transaction knows about.

“Free . . .” Lists

Lists of owners, resources, and requests are chained forward and backward. An offset in each block contains the pointer to the next block. The lists of offsets are used when the Lock Manager needs to allocate a new block and tries to find blocks that are free to be reused. It will allocate a new block only if there are no free blocks of the right type and size.

The “free. . .” items indicate the forward and backward pointers to the offsets of the first and last free request blocks, respectively.

Deadlocks

A deadlock occurs when Owner A wants a lock on Resource 1, which is held in an incompatible mode by Owner B, and Owner B wants a lock on Resource 2, which is held in an incompatible mode by Process A. A deadlock can also occur with a single resource if both owners start with read locks and request conversions to write locks.

It is a standoff that the owners cannot resolve without intervention. Resolution comes once the deadlock is detected by the next scan and the lock manager returns a fatal error to one owner or the other. The default deadlock scan interval —DeadlockTimeout in the configuration file—is 10 seconds. They are not done under every condition where there is a WAIT. Waiting is normal in a system that manages parallel updates, and unnecessary scanning is costly.

“Deadlocks”That Are Not Deadlocks

The deadlocks reported may not help to pinpoint “deadlock problems” observed in your applications. Deadlocks always involve two owners (or two separate transactions), each being stymied by the other. Firebird tends to deliver “deadlock” messages to clients for most types of locking conflict, even though a true deadlock—such as would be reported in a lock print—is relatively rare.

• Errors that are returned as “lock conflict” from NO WAIT lock requests are not recorded in the lock table as deadlocks because only one owner is waiting.
• Errors returned as “deadlock” with the secondary message “Update conflicts with concurrent update” are not actual deadlocks either. What has happened in those cases is that one owner has modified (or deleted) a row and moved on. Another concurrent owner has attempted to modify (or delete) the same record, has waited for the first owner to release it, and now fails because the latest committed version has changed.

The lock table data can be reported in a more or less human-readable format, by way of the Lock Print utility.