User Input File Requirements
Transaction Manager
You need to implement your own Transaction Manager according to two-phase commit protocol. The communication interfaces between Transaction Manager, Resource Manager and Application Program are revised from the X/Open standard. See the figure and description below (1),(3),(4) -the Blue color font are for the TM specially.
Figure 1 communication sequence between AP, TM and RM.
(1) : Ap first called tx_begin() through TM’s TX interface to gain the global transaction ID.
(2): Then AP initiates its sub-transactions. Assuming that there are 2 subtrasactions so AP has to call the native methods of RMproxy1 and RMproxy2 respectively. About what methods are available please refer to API for ResourceManager class.
(3): When RM proxy got the initialization request from AP, it will then call ax_reg() through TM’s AX interface to register itself to the TM.
(4): After all its sub-transactions successfully registering to TM, AP will call tx_commit() through TM’s TX interface and two phases commit protocol starts after this call.
(5):TM start to perform the two phases commit protocol and it communicate with RM(s) through the XA interface of RM(s).
The Transaction Manager has to implement the TMInterface that extends another 2 interfaces, please refer the Class Diagram below.
- AX is the name of the services shared by the TM and the RM. The AX services are provided by TM and are called by RMs.
-
TX is the name of the service shared by the AP and the TM. The TX functions are provided by TM and are called by APs.
Figure 2 Class Diagram
File Name Restriction
None
How to implement the Transaction Manager ?
You have to implement 4 methods from AX and TX interface respectively. To see the detail description for the methods, please refer to the API - AX, TX.
One thing worth to mention is about the static variable runningTrans in the TMInterface. It is the hash table stored all the running transaction using global transaction id as the key and TransactionRecord as the value. The TransactionRecord is a object that keeps a list of registered ResourceManager for that transaction. The Figure 3 illustrates this relation.
Figure 3 integral of runningTrans
The reason why you need a data structure to keep this relation is because each global transaction can contain a number of cohorts(ResourceManager), and Transaction Manager should be able to track all the cohorts for specific transaction by given the transaction Id. For example, when transaction 1 decided to commit, then Transaction Manager can first obtain TransactionRecord for transaction 1 and call getAllRMs() to get all the registered RMs. Then for each cohort call ResourceManager.xa_commit() . Therefore, in your implementation , you should use runningTran and TransactionRecord to ensure transaction and its responding Resource Manager has registered/unregistered properly.
Sample File
The skeleton of Transaction Manager is provided here.
Back
to User Input File Requirements