Introduction
Dblqh is the coordinator of the LDM. Dblqh is responsible for performing operations on tuples. It does this job with help of Dbacc block (that manages the index structures) and Dbtup (that manages the tuples).
Dblqh also keeps track of the participants and acts as a coordinator of 2-phase commits. Logical redo logging is also handled by the Dblqh block.
Modules
The code is partitioned into the following modules:
- START / RESTART
- Start phase 1: Load our block reference and our processor id
- Start phase 2: Initiate all records within the block Connect LQH with ACC and TUP.
- Start phase 4: Connect LQH with LQH. Connect every LQH with every LQH in the database system. If initial start, then create the fragment log files. If system restart or node restart, then open the fragment log files and find the end of the log files.
- ADD / DELETE FRAGMENT
Used by dictionary to create new fragments and delete old fragments.
- EXECUTION
handles the reception of lqhkeyreq and all processing of operations on behalf of this request. This does also involve reception of various types of attrinfo and keyinfo. It also involves communication with ACC and TUP.
- LOG
The log module handles the reading and writing of the log. It is also responsible for handling system restart. It controls the system restart in TUP and ACC as well.
- TRANSACTION
This module handles the commit and the complete phases.
- MODULE TO HANDLE TC FAILURE
- SCAN
This module contains the code that handles a scan of a particular fragment. It operates under the control of TC and orders ACC to perform a scan of all tuples in the fragment. TUP performs the necessary search conditions to ensure that only valid tuples are returned to the application.
- NODE RECOVERY
Used when a node has failed. It performs a copy of a fragment to a new replica of the fragment. It does also shut down all connections to the failed node.
- LOCAL CHECKPOINT
Handles execution and control of LCPs It controls the LCPs in TUP and ACC. It also interacts with DIH to control which GCPs are recoverable.
- GLOBAL CHECKPOINT
Helps DIH in discovering when GCPs are recoverable. It handles the request gcp_savereq that requests LQH to save a particular GCP to disk and respond when completed.
- FILE HANDLING
With submodules:
- SIGNAL RECEPTION
- NORMAL OPERATION
- FILE CHANGE
- INITIAL START
- SYSTEM RESTART PHASE ONE
- SYSTEM RESTART PHASE TWO,
- SYSTEM RESTART PHASE THREE
- SYSTEM RESTART PHASE FOUR
- ERROR
- TEST
- LOG
Definition at line 43 of file Dblqh.hpp.