откуда - the lock table & Transaction Inventory Page
1) доступ к the lock table - из lock manager
2) доступ к Transaction Inventory Page - это просто страница базы (файла базы)
1) доступ к the lock table - из lock manager
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.
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.
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.
Transaction Inventory Page
Page Type 3 is a transaction information page (TIP). The TIP header includes the address of the next TIP.
The body of a TIP is an array of pairs of bits that reflect the state of transactions. If both bits are 0, the transaction is active or has not started. If both bits are 1, the transaction is committed. If the first bit is 1 and the second bit is 0, the transaction rolled back. If the first bit is 0 and the second is 1, the transaction is in limbo.
Limbo is the state of a two phase transaction that has completed the first phase, but not the second.
Самое замечательное во всей этой штуке - то, что можно вытаскивать по одной штуке - и отлаживать :
Хотим получить поведение кластера - аналогично поведению одного сервера.
вторая итерация - кластеров скл серверов.