|
|
|
|
|
|
Using GTRID Mapping in Transactions
In the BEA Tuxedo system, a transaction tree is a 2-level tree where the root is the gateway group coordinating a global transaction and branches are involved in the transaction. Each group performs its part of the global transaction independently from the parts performed by other groups. Each group, therefore, implicitly defines a transaction branch. The BEA Tuxedo system, through Transaction Manager Servers (TMSs), coordinates the completion of the global transaction, making sure each branch is completed.
A GTRID is a Global Transaction Identifier. GTRID mapping defines how to construct a transaction tree that crosses domain boundaries. You specify GTRIDs using the MAXGTT parameter in the RESOURCES section of the configuration file.
Defining Tightly-coupled and Loosely-coupled Relationships
In the X/Open DTP Model, a Transaction Manager Server can construct transaction trees by defining either tightly-coupled or loosely-coupled relationships with a Resource Manager (RM) by the way it interprets the transaction identifiers (XIDs) used by the XA interface.
A tightly-coupled relationship is one in which a single transaction identifier, XID, is used by all processes participating in a single global transaction, accessing a single RM. This relationship maximizes data sharing between processes; XA-compliant RMs expect to share locks for resources used by processes having the same XID. The BEA Tuxedo system achieves the tightly-coupled relationship via the group concept; that is, all work done by a group on behalf of a given global transaction belongs to the same transaction branch; all the processes executed by the group are given the same XID.
In a loosely-coupled relationship, the TMS generates a transaction branch for each part of the work in support of the global transaction. The RM handles each transaction branch separately; there is no sharing of data or of locks between the transaction branches. Deadlocks between transaction branches can occur and result in the rollback of a global transaction. In the BEA Tuxedo application, when different groups participate in a single global transaction, each group defines a separate transaction branch, which results in a loosely-coupled relationship.
Global Transactions Across Domains
There are several differences between global transactions in a single BEA Tuxedo application and global transactions across domains. The first difference is that in the Domains framework, the transaction tree cannot be flattened to a 2-level tree. There are two reasons for this:
This means that the commitment protocol across domains must be hierarchical. Even a loop-back service request defines a new branch in the transaction tree.
Note: A loop-back request goes to another domain and then comes back to be processed in the original domain. For example, domain A requests a service of domain B. The service in domain B requests another service in domain A. The transaction tree has two branches at the network level: a branch b1 from A to B and a branch b2 from B to A. Domain A cannot commit the work done on branch b2 before receiving commit instructions from B.
The structure of a transaction tree for global transactions across domains also depends on the distributed transaction processing protocol used by a relevant Domains instantiation. For example, in the OSI TP protocol each dialogue (the OSI TP word for a service request) is associated with a different transaction branch. In the BEA Tuxedo system, the OSI TP instantiation uses a dialogue for each service request, so each service request is mapped to a separate transaction branch. The XAP-TP interface hides this mapping and provides a mechanism by which an entire OSI TP subtree can be referenced by a user-defined identifier. (In the BEA Tuxedo implementation, this identifier is the GTRID.) The GTRID is used to instruct XAP-TP how a transaction tree must be constructed, that is, which dialogues must be included within a given OSI TP transaction. Therefore, from the BEA Tuxedo perspective, a whole OSI TP subtree can be managed as a single transaction branch.
This property, however, applies only to outgoing service requests (that is, service requests sent from the root domain to subordinate domains). It cannot be applied to incoming service requests. The OSI TP instantiation consequently implements a loosely-coupled relationship; each incoming service request is mapped to a new BEA Tuxedo global transaction.
The TDOMAIN instantiation tries to optimize GTRID mapping by implementing a tightly-coupled relationship. In TDOMAIN, multiple service requests issued on behalf of the same global transaction are mapped to the same network transaction branch. Therefore, incoming service requests can be mapped to a single BEA Tuxedo transaction. However, the hierarchical structure of interdomain communication and the interdomain transaction tree must still be maintained.
The optimization that TDOMAIN introduces applies only to a single domain. When two or more domains are involved in a transaction, the network transaction tree contains at least one branch per domain interaction. Hence, across domains, the network transaction tree remains loosely-coupled. There are as many branches as there are domains involved in the transaction (even if all the branches access the same resource manager instance).
Domains gateway groups implement a loosely-coupled relationship because they generate different transaction branches for interdomain transactions.
Example of a Service Request Graph Generating Local and Remote Requests
The following figure shows the service request graph for a client that generates three service requests: one local request (r0) and two remote requests (r2 and r3). Request r0 goes to a local service (Svc0), which generates another remote service request (r1). Request r1 goes to remote service Rsvc1, which issues a loop-back service request r4 to local service Svc4. Svc0 and Svc4 are executed in different groups (G0 and G4). The domain gateway is executed within another group (GW), and the remote services Rscv1, Rsvc2, and Rsvc3 are executed in another domain (domain B).
Service Request Graph
Transaction Trees for BEA eLink for Mainframe-OSI TP and BEA Tuxedo Domains
The following two figures show the transaction tree for BEA eLink for Mainframe-OSI TP and the transaction tree for BA Tuxedo Domains. It is assumed, in these figures, that both domains A and B are BEA Tuxedo system applications.
BEA eLink for Mainframe-OSI TP is loosely-coupled because of the OSI TP protocol. The transaction tree for this instantiation shows group G0 in Domain A coordinating the global transaction started by the client. Group G0 coordinates group GW. Requests r1, r2, and r4 are mapped each to an OSI TP dialogue and therefore to an OSI TP transaction branch. However, OSI TP uses the XAP-TP feature that allows an entire OSI TP transaction to be referred by a unique identifier (T1) and uses this identifier for requests r1, r2, and r3. It is up to XAP-TP to generate OSI TP transaction identifiers and to construct the corresponding OSI TP transaction tree. The only function that must be performed by the generic Domains software is the mapping of service requests r1, r2, and r3 to the T1 identifier.
In Domain B, OSI TP uses the rule that new transaction branches must be mapped to a new BEA Tuxedo transaction. Therefore, OSI TP transaction branches r1, r2, and r3 get mapped to three different BEA Tuxedo transactions (the corresponding mapping is represented by identifiers T2, T3, and T4). The graph shows the gateway group GW in Domain B coordinating three BEA Tuxedo transactions on group G1.
Finally, there is the loop-back service request r4 that generates another branch in the transaction tree. OSI TP maps this request to identifier T2, but XAP-TP generates a new branch in its transaction tree (r4: B to A'). This is a new transaction branch on Domain A, and therefore, the gateway generates a new mapping T5 to a new BEA Tuxedo transaction. Therefore, the transaction graph shows that gateway group GW on Domain A coordinates group G4.
Notice that the hierarchical nature of the OSI TP protocol is fully enforced by these mappings. However, because these mappings introduce a loosely-coupled relationship, the probability of intratransaction deadlock is increased (for example, there are three BEA Tuxedo transactions accessing the RM represented by group G1).
Transaction Tree for BEA eLink for Mainframe-OSI TP Environment
The TDOMAIN instantiation provides a tightly-coupled integration that solves this deadlock problem by minimizing the number of transaction branches required in the interoperation between two domains. The corresponding transaction tree is shown in the following figure.
Transaction Tree for TDOMAIN Environment
Notice that the gateway still must perform mappings between a BEA Tuxedo system transaction and a network transaction, and that the hierarchical nature of the communication between domains must be strictly enforced. The diagram shows that requests r1, r2, and r3 are mapped to a single TDOMAIN transaction branch. Therefore, on domain B only one BEA Tuxedo system transaction needs to be generated; T2 represents this mapping and the graph shows gateway group GW on domain B coordinating group G1. Request r4 is mapped to identifier T2 on Domain B, but TDOMAIN will generate a new branch in its transaction tree (r4: B to A'). Because this is a new transaction branch on Domain A, the gateway generates a new mapping, T3, to a new BEA Tuxedo system transaction. The graph shows that gateway group GW on Domain A also coordinates group G4. Hence, the hierarchical nature of interdomain communication is fully enforced with this mapping: group G4 cannot commit before group G1.
Summary of Domains Transaction Management
Domains transaction management can be summarized as follows:
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|