Skip navigation links
6.4.8 The DBTUP Block »
Section Navigation      [Toggle]

6.4.7. The DBTC Block

This is the transaction coordinator block, which handles distributed transactions and other data operations on a global level (as opposed to DBLQH which deals with such issues on individual data nodes). In the source code, it is located in the directory storage/ndb/src/kernel/blocks/dbtc, which contains these files:

  • Dbtc.hpp.  Defines the Dbtc class 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 LQH connect record takes care of waiting for an operation to complete; when an operation has completed on the LQH connect record, a new operation can be started on the current LQH connect record. ApiConnectRecord is 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 LQH connection record for communication with any local query handlers involved in the transaction. TcConnectRecord) is permanently connected to a record in DBDICT and another in DIH, and contains a list of active LQH connection records and a list of started (but not currently active) LQH connection records. It also contains a list of all operations that are being executed with the current TC connection record. TcConnectRecord is always 128-byte aligned.

    • Cache record (CacheRecord).  This record is used between reception of a TCKEYREQ and sending of LQHKEYREQ (see Section 6.3.3, “Operations and Signals”) This is a separate record, so as to improve the cache hit rate and as well as to minimise 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 ScanRecord to 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) ATTRINFO signal, 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 GcpRecord is 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 Dbtc indexes and data (includes class desctructor).

  • DbtcMain.cpp.  Implements Dbtc methods.

Note

Any data node may act as the transaction coordinator.

The DBTC block is implemented as the Dbtc class.

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.