GCOS 8: TP8 Connect

Implementation of cooperating GCOS 8/TP8 - Tuxedo applications is based upon
the 3 Interoperability 8 solutions:
- TP8 connect with Tuxedo
- Reverse TP8 connect with Tuxedo
- XA8 for Tuxedo

The full capability of a client/server architecture between TP8 and Tuxedo applications with a possible secured and consistent updating of the databases driven by both TP monitors is thus offered.

As their names imply, "TP8 Connect" and "Reverse TP8 Connect" are mirror-image mechanisms. They are used exclusively for non-conversational interchanges between transactional applications developed on GCOS 8/TP8 and Tuxedo. Both of these mechanisms can enable the use of existing programs

- With "TP8 connect", applications developed with Tuxedo can access GCOS 8 resources via applications developed with TP8. The data interchange is based on a client/server model of Tuxedo : Tuxedo applications using "TP8 connect" are clients of the TP8 application servers. As such, they are the only ones that can initiate a transaction.

TP8 Connect

TP8 Connect

- With "Reverse TP8 connect", applications developed with TP8 can access Tuxedo services via applications developed with Tuxedo. The data interchange is based on a client/server architecture: the TP8 applications using "Reverse TP8 connect" are clients of the Tuxedo server applications

Reverse TP8 Connect

Reverse TP8 Connect

"TP8 connect" and "Reverse TP8 connect" is a renewal of the previous /HOST8 and Reverse /HOST8.

Transactional architecture : a reminder

Derived from large centralized transaction processing applications on mainframes, driving thousands of workstations, the concept of transaction processing has been extended to distributed systems.

Thereby X/Open has defined a DTP ( Distributed Transaction Processing) model that fulfills ACID (Atomicity, Consistency, Isolation, Durability) properties of transactions. For the support of the two-phase commit protocol, the X/Open DTP model specifies an XA interface between a TM (Transaction Manager) coordinating a global distributed transaction that will update consistently multiple RM's (Resource Manager) .The TP monitor and its TM will thus ensure that the shared resources -e.g. RDBMS- managed by the coordinated RM's, will be synchronously updated.

the X/OPEN DTP model

• Transaction Manager coordinates the Global Transaction involving multiple Resource Managers that have to be updated consistently

(°) based upon Tuxedo

Jointly specified with the Tuxedo TP monitor architects at the early stage of X/Open DTP model definition, TM's are now implemented in other TP monitors such as Encina and more recently in Microsoft MTS (Microsoft Transaction Server).
Main RDBMS (Relational Data Base Management System) vendors have implemented XA-compliant RM's.

XA8 : GCOS 8 supports the XA protocol as a RM

The robustness of the transaction processing capabilities of GCOS 8/TP8 has been expanded to GCOS 8 platforms cooperating with distributed systems : GCOS 8, to be considered as a RM, supports the XA protocol.
As such, GCOS 8 TP/DB applications can be coordinated by the Tuxedo TM in the same distributed global transaction. This new facility will be offered to the large segment of our GCOS 8 customers who have deployed cooperating applications between Tuxedo and TP8 platforms. Thanks to XA8, a global transaction , coordinated by Tuxedo, is now able to fulfill transactional integrity while updating GCOS 8 databases and other database servers supporting the XA protocol.

The XA-RM property of GCOS 8/TP8 extends the range of TP8 transactional processing cooperation : from the moment that an application server is built on a TP monitor that supplies a TM supporting the XA protocol, it will ensure cooperative transactional integrity with TP8 applications.

XA8 architecture

Retaining the robustness of transaction processing capabilities of GCOS 8 is the main concern of our customers when they integrate distributed applications with GCOS 8/TP8 : the support of XA protocol by e-business infrastructure will be a key success factor for a seamless GCOS 8 enterprise application integration with e-business solutions.

Global Transactions Management (2 phase commit protocol ) : a tutorial

The 2 phase-commit protocol is used to synchronize updates on different machines so that they either all fail or all succeed.ISO defined rigidly the OSI-TP standard 2pc protocol :

1. In the 1st phase of a commit, the commit manager node -aka the root node or the transaction coordinator- sends prepare_to_commit commands to all subordinate nodes that were asked to participate to the transaction.The subordinates may have pieces of the transaction on other nodes (or Resource Managers) to which they must propagate the prepare_to_commit command.
=> transaction tree with coordinator at the root.

2. The 1st phase of the commit terminates when the root receives ready_to_commit from all its direct subordinate nodes that participe to the transaction.This means that the transaction has executed successfully so far on all the nodes and they 're ready for a final commit.

3. The 2nd phase of the commit starts after the root node makes the
decision to commit the transaction-based on the unanimous YES vote => subordinates to commit down the tree.

4. The 2nd phase of the commit terminates when all the nodes involved have safely commted their aprt of the transaction to make it durable. The root receives all the confirmations and can tell its client that the transaction completed. It can relax until the next transaction

5. The two-phase commit aborts if any of the participants return a refuse indication, meaning that their part of the transaction failed . In that case , the root node tells all subordinates to perform a roll-back. And they , in turn, do the same for their subordinates.

The two-phase commit protocol (*)

(*) From « The essential C/S survival Guide »Orfali &al.