Continuing with our example, we now examine how transaction adapters work behind the scenes to support extended transaction behavior on a legacy TP monitor. We begin with the instantiate meta interface command in line 2. During execution, the instantiate command causes control to be passed to the Transaction Management Adapter, which first creates a metatransaction descriptor and reifies information for the transaction PE_Tran, including the transaction identifier (TRID), current execution status of the transaction, and control operations available to the transaction. Next, the Transaction Management Adapter directs the other adapters to create initial entries for objects will be reified for this transaction during its execution, and then it returns control back to the base transaction for processing. The reflect command in line 3 also causes control to be passed to the Transaction Management Adapter, which updates the metatransaction descriptor, as illustrated below, to contain the transaction control operations split and join, specified by the split/join extended transaction model.
metatransaction Descriptor{
myid is TRID;
execMode is Active;
initiateOperations: {<Begin,atomicBegin>};
processOperations: {<Split,splitOperation>};
terminateOperations: {<Commit,atomicCommit>,
<Abort,atomicAbort>,
<Join,joinOperation>}};
Processing resumes on the base TP monitor, until the transaction control operation split(CE_Tran, Subsystem) is processed in line 4. Split is a transaction control operation defined the extended transaction interface for the transaction PE_Tran. When the transaction invokes a control operation, the actual code executed is determined by its metatransaction (see Figure 8). When the split operation is invoked by the transaction, processing involves first verifying this control operation is permitted for the transaction, and once it has been verified then the function is executed, as illustrated in Figure 8. For the execution of the split operation, as defined in Figure 6, the first meta interface command directs the Transaction Management Adapter to create a metatransaction descriptor for the new transaction CE_Tran. This change is reflected down onto the TRANSACTION MANAGER, resulting in the creation of a new base level transaction. The commands instantiate and reflect are then processed by the Transaction Management Adapter to initialize the meta objects for the transaction CE_Tran. Next, the Lock Adapter delegates locks on all data objects in the delegate set Subsystem from the transaction PE_Tran to the transaction CE_Tran. This change is first made first to the meta object lockTable, and through causal connection the change is reflected down to the LOCK MANAGER through the API commands releaseLock and acquireLock. Once the delegate_lock command is complete, the Transaction Management Adapter processes the delegate_op command. Finally, the begin command is processed by the Transaction Management Adapter, which sets the execution mode of the transaction CE_Tran to active and returns control to the TP monitor to begin base level processing.
