This is the transaction coordinator block, which handles
distributed transactions and other data operations on a global
level (as opposed to
which deals with such issues on individual data nodes). In the
source code, it is located in the directory
contains these files:
Dbtc.hpp: Defines the
Dbtcclass and associated constructs, including the following:
Trigger and index data (TcDefinedTriggerData). A record forming a list of active triggers for each table. These records are managed by a trigger pool, in which a trigger record is seized whenever a trigger is activated, and released when the trigger is deactivated.
Fired trigger data (TcFiredTriggerData). A record forming a list of fired triggers for a given transaction.
Index data (TcIndexData). This record forms lists of active indexes for each table. Such records are managed by an index pool, in which each index record is seized whenever an index is created, and released when the index is dropped.
API connection record (ApiConnectRecord). An API connect record contains the connection record to which the application connects. The application can send one operation at a time. It can send a new operation immediately after sending the previous operation. This means that several operations can be active in a single transaction within the transaction coordinator, which is achieved by using the API connect record. Each active operation is handled by the TC connect record; as soon as the TC connect record has sent the request to the local query handler, it is ready to receive new operations. The
LQHconnect record takes care of waiting for an operation to complete; when an operation has completed on the
LQHconnect record, a new operation can be started on the current
ApiConnectRecordis always 256-byte aligned.
Transaction coordinator connection record (TcConnectRecord). A
TcConnectRecord) keeps all information required for carrying out a transaction; the transaction controller establishes connections to the different blocks needed to carry out the transaction. There can be multiple records for each active transaction. The TC connection record cooperates with the API connection record for communication with the API node, and with the
LQHconnection record for communication with any local query handlers involved in the transaction.
TcConnectRecord) is permanently connected to a record in
DBDICTand another in
DIH, and contains a list of active
LQHconnection records and a list of started (but not currently active)
LQHconnection records. It also contains a list of all operations that are being executed with the current TC connection record.
TcConnectRecordis always 128-byte aligned.
Cache record (CacheRecord). This record is used between reception of a
TCKEYREQand sending of
LQHKEYREQ(see Section 3.3, “Operations and Signals”) This is a separate record, so as to improve the cache hit rate and as well as to minimize memory storage requirements.
Host record (HostRecord). This record contains the “alive” status of each node in the system, and is 128-byte aligned.
Table record (TableRecord). This record contains the current schema versions of all tables in the system.
Scan record (ScanRecord). Each scan allocates a
ScanRecordto store information about the current scan.
Data buffer (DatabufRecord). This is a buffer used for general data storage.
Attribute information record (AttrbufRecord). This record can contain one (1)
ATTRINFOsignal, which contains a set of 32 attribute information words.
Global checkpoint information record (GcpRecord). This record is used to store the globalcheckpoint number, as well as a counter, during the completion phase of the transaction. A
GcpRecordis 32-byte aligned.
TC failure record (TC_FAIL_RECORD). This is used when handling takeover of TC duties from a failed transaction coordinator.
DbtcInit.cpp: Handles allocation and deallocation of
Dbtcindexes and data (includes class desctructor).
Any data node may act as the transaction coordinator.
DBTC block is implemented as the
The transaction coordinator is the kernel interface to which applications send their requests. It establishes connections to different blocks in the system to carry out the transaction and decides which node will handle each transaction, sending a confirmation signal on the result to the application so that the application can verify that the result received from the TUP block is correct.
This block also handles unique indexes, which must be co-ordinated across all data nodes simultaneously.