|
|
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
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:
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:
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.
The lock table data can be reported in a more or less human-readable format, by way of the Lock Print utility.
|
|
Firebird Related Tutorials |
|
---|---|
MySQL Tutorial | Linux Tutorial |
Windows 10 Tutorial | Windows 10 Development Tutorial |
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.