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
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
connect record, a new operation can be started on the
LQH connect record.
ApiConnectRecord is always 256-byte
Transaction coordinator connection record (TcConnectRecord).
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
DIH, and contains a list
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
Cache record (CacheRecord).
This record is used between reception of a
TCKEYREQ and sending of
Section 8.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
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
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
Dbtc indexes 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.