Transaction Manager


The Transaction Manager maintains information about all transactions in the system. It also provides methods using which the Lock Manager and the Recovery Manager can obtain information from the shared memory regions (for example, the Recovery Manager requires information from the dirty page table during checkpointing ). In addition, the TM manages information about the process ids of the clients in the system. This is information required by the Minibase server.

Design Decisions

Every process is a transaction in the Minibase multi-user model. The Minibase server is transaction 0. Subsequent transactions are assigned sequential transaction identifiers. Nested transactions from a single process are not possible in the current design of the Minibase system. Nested transactions may be modelled by transactions from different clients, that attach to the Minibase server.

The base xaction_manager class includes one key data structure --- an array of pointers to transactions. The transaction class is derived from the base SharedRegion class and contains data critical to the Lock Manager and the Recovery Manager.

The transaction maintains a linked list of lock queues. Each element in this list points to a lock entry which holds information about the page which the transaction has a lock on. There are thus as many entries in the list as there are pages that the transaction has a lock on.
It also maintains information about the last LSN and the minimum LSN associated with the transaction. For more details about LSNs and their use in recovery, refer to details about the Log Manager.

The transaction manager also maintains some information about the clients in the system, namely their process identifiers and a flag indicating the validity of a transaction. This is required by the Minibase server for deadlock detection and resolution.

Click here for the public interface.
Click here for details on Transaction Manager implementation.

Back to the List of Components
Back to the Minibase Home Page