Firebird, however, manages its locks in a shared memory section. In SuperServer, only the server uses that share memory area. In Classic, every database connection maps the shared memory and every connection can read and change the contents of the memory.
The lock table is a separate piece of share memory. In SuperServer, the lock table is mapped into the server process. In Classic, each process maps the lock table. All databases on a server computer share the same lock table, except those running with the embedded server.
Firebird locking summary
Although Firebird does not lock records, it uses locks extensively to isolate the effects of concurrent transactions. Locking and the lock table are more visible in Firebird than in other databases because the lock table is a central communication channel between the separate processes that access the database in Classic mode. In addition to controlling access to database objects like tables and data pages, the Firebird lock manager allows different transactions and processes to notify each other of changes to the state of the database, new indexes, etc.
Firebird lock manager
We often talk about the Firebird Lock Manager as if it were a separate process, but it isn’t. The lock management code is part of the engine, just like the optimizer, parser, and expression evaluator. There is a formal interface to the lock management code, which is similar to the formal interface to the distributed lock manager that was part of VAX/VMS and one of the interfaces to the Distributed Lock Manager from IBM.
The lock manager is code in the engine. In Classic, each process has its own lock manager. When a Classic process requests or releases a lock, its lock management code acquires a mutex on the shared memory section and changes the state of the lock table to reflect its request.
