Lock Management in Firebird

Lock Management and Versioning

'Wait!' you say, 'Firebird doesn't lock records, it uses multi-version concurrency." And that's true. However, there are two types of concurrency in Firebird, one based on transactions and visible to clients and one instantaneous and controlled by the system itself.

The rules for transaction based locking are that locks can be acquired at any point during the transaction but can only be released at the end. Firebird 1.5 added a specific syntax for locking records:

select <blah> for update with lock

There is no equivalent unlock statement. The commit or rollback of the transaction releases the lock. "Two phase locking" is a standard database technique. When used with write locks, it provides a low level of consistency - eliminating dirty reads and writes but nothing more. When used with both read and write locks,` it provides a higher level of consistency - but not repeatable read - at the cost of terrible concurrency. That is why Firebird doesn't use record locks as its primary concurrency control.

Firebird does use locks to keep two transactions from writing to the same page at the same time. These locks must be held for the amount of time the transaction needs to complete its changes to the page. When the changes are complete, the lock can be released. Normally the lock is held until some other transaction needs to use the page because many transactions make several change to a page before they complete.

Firebird provides external concurrency and consistency control through record versions. It maintains the consistency of the on-disk structure through locks and careful write.

Locking

Firebird uses the operating system locking services to control access to database files. The operating system lock prevents the SuperServer from opening the same file twice under different names. A valuable service, but not interesting.

The interesting part of lock management in Firebird is that provided, in general, by our own lock manager. Our lock manager is modeled on the VAX/VMS Distributed Lock Manager which handled locks in a VAX Cluster. Like contemporary clusters, a VAX Cluster is a group of machines that share access to disks but not memory. Over time, the InterBase lock manager drifted from the VMS lock manager and everyone (nearly everyone) drifted away from VMS.

The mechanism used to create software locks varies, but for Firebird, a lock is represented by structures in memory. One is the object (or concept) to be locked. The others are requests for locks. Each request block indicates whether or not the requester can share the object with others. Each object has a list of some number of request blocks that are currently holding locks on the object and a second list of some number of request blocks that are waiting for the lock.

The lock manager is a memory region containing lock blocks, request blocks, owner blocks, and other useful blocks. The lock manager is also manipulation routines that request, acquire and release locks on resources. It is convenient to describe and think about the lock manager as a separate entity with which database processes communicate rather than as subroutines in each process. That's the way it works in SuperServer. In classic, processes line up to get control of the lock table so their lock management code can queue, grant, and release locks. SuperServer is also somewhat more complex than this description because in addition to locks, it has "latches", which co-ordinate changes by concurrent transactions.

This document is a short extract from a much larger document entitled "Reading A Lock Print". The first in a series of advanced articles on specific aspects of Firebird and InterBase for the IBPhoenix Developer DVD.

This paper was written by Ann Harrison in June 2003, and is copyright Ms. Harrison and IBPhoenix Inc. You may republish it verbatim, including this notation. You may update, correct, or expand the material, provided that you include a notation that the original work was produced by Ms. Harrison and IBPhoenix Inc.