DTC

Distributed Transaction Controller (DTC) provides overall transaction orchestration, where users can implement a state machine in Cloverleaf.

With DTC, messages can be temporarily stored, translated, enriched by querying external systems or otherwise and sent when ready for outbound.

Using DTC, users have control to commit, rollback, or proceed to the next step depending on success or error in the transaction states. The transaction states and associated actions are user defined.

DTC transactions are tracked in a site-specific database, which gives DTC the capability to work across all processes and threads in a site.

These major components are part of a transaction system:

  • Binary engine:

    This runs the list of steps in a pre-determined order. There are various protocols that the binary engine follows, such as 2-phase commit, 3-phase commit and Paxos.

  • List of steps to run:

    This is a pre-determined ordered list. For example, by a query planner, and handed to the binary engine. Each step runs successfully or with an error. If an error, then the binary engine rolls back the transaction by undoing the result of the previous successful steps.

  • Rollback journal:

    This stores undo information, which is stored on disk. This is a special table that is accessible only by the binary engine, and stores the values before a step changes it. On running the command, the binary engine first copies the step’s *main data* into the rollback journal and then runs the step. If the step was successful, then it moves to the next step. If unsuccessful, then the binary engine overwrites the *main data* with the value from the rollback journal for this and all previously run steps.

DTC provides coordination and transaction functionality between several independent threads that may be in the same Cloverleaf instance.

With DTC, messages can be temporarily stored, enriched by querying external systems or otherwise, and sent when ready for outbound.

DTC auto-commits. Users have control of proceeding to the next step or rollback, depending on success or error in the transaction states. The transaction states and associated actions are user-defined.

DTC is implemented as a protocol in Cloverleaf. DTC threads are the binary engine that runs the transaction.

On the DTC’s IDE, users can create the list of steps in the form of a state machine. Action TPS are run with each step and govern the flow of the state machine, providing an order for the list of steps. In other words, users are the query planner when they use the DTC’s IDE to build the state machine and write Action TPS. Rollback TPS cannot be used to handle error conditions.

A Staging DB is created to handle the Rollback Journal functionality. This is a general feature and can be used without DTC. The Staging DB stores key value pairs under an umbrella key space. Each transaction creates its own key space and support for global key space is available.

Engine commands are provided to assist with debugging. For example, when *dtc_debug step* is set, the binary engine waits before running the next step. It only does so when *dtc_debug step* is run from the command line.

CLAPI support is included to configure the DTC thread and properties.

Information storage

Distributed Transaction Controller files are stored in $HCISITEDIR/dtc.

The staging database, $HCISITEDIR/exec/databases, is used for DTC state tracking.