As discussed onpage 1-6, aDTP application consists of a client program and at least one server program, which communicate by service requests. To coordinate the communication of the service requests, an X/OpenDTP appli- cation can use theTM.
Figure 1-6 shows how theTM manages the routing of service requests. Figure 1-6 TM Service-Request Routing Database server RM TM system User Client Service request Service request Call service 2. (Database C) Service 2 executes, Service confirmation Service confirmation AP Service 2 Service 3 Server II User request Service data 6 2 5 1 8 7 3 4 custno custname 1234 XYZ LTD 1235 XSPORTS Database C
The Transaction Manager
As shown inFigure 1-6 on page 1-18, theTM routes a service request in the following steps:
1. The user enters information needed for the transaction. 2. The client program creates a service request for Service 2. 3. The client program sends this service request to theTM.
4. TheTM routes the service request to the server program of the appro- priateRM. In this case, theTM routes the request to theRM that contains ServerII, where Service 2 is located.
5. The server program, ServerII, locates the Service 2 service and executes it. In the course of this execution, the Service 2 program accesses Database C through the associatedDBMS.
6. The ServerII server program sends theTM a confirmation that the service has executed. It then sends to theTM any data that theDBMS returned.
7. TheTM routes the service confirmation to the appropriate client program (the application program). If the service has returned any data, theTM also routes this data to this client.
8. The client program (the application program) displays any data that is appropriate for the user.
The Transaction Manager
To handle these service requests, theTM defines and manages a request queue, which stores information about the state of a transaction. The request queue, shown in Figure 1-7, is a piece of shared memory that theTM defines and manages.
Important: Because the design and implementation ofTMs is not governed by any specification, yourTM might not handle server requests as described in Figure 1-7.
Controlling the Two-Phase Commit
In an X/OpenDTP model, the two-phase commit protocol is handled by the following two parts:
■ TheTM is the coordinator, directing the execution of the global transactions.
■ EachRM is a participant, directing the execution of one transaction branch.
For definitions of coordinators and participants, seepage 1-10.
Figure 1-7 The TM Request Queue
Service 1 Client TM software system AP TM RM Server DBMS Request queue custno custname 1234 XYZ LTD 1235 XSPORTS Database
The Transaction Manager
Phase 1: The Precommit Phase
1. The application program initiates the two-phase commit by notifying theTM that it wants to commit the global transaction. 2. TheTM asks eachRM if it is prepared to commit its transaction
branch. To do this, theTM calls the xa_prepare()XA interface routine. 3. If theRM determines that it can commit the transaction branch, it
records this information in a log and sends an affirmative reply to the TM. If theRM cannot commit the transaction branch, it aborts it and sends a negative reply to theTM.
Phase 2: The Postdecision Phase
1. If theTM receives any negative replies or no reply, it asks the other RMs to abort their transaction branches by calling the xa_rollback() XA interface routine for each one.
2. If allRM replies are affirmative, theTM first records the fact that it has decided to commit the global transaction along with a list of the involvedRMs (excluding those that responded with a read-only status). It then asks eachRM to commit its transaction branch by calling the xa_commit()XA interface routine for each one. TheTM forgets about the transaction branch after all xa_commit() routines are complete.
For information on how the database server participates in the two-phase commit, see“The Database Server and the Two-Phase Commit Protocol” on page 2-11. For more information on theXA interface, see“The XA Interface” on page 1-24.
Before it can call any otherXA routine, theTM must first initialize theRM by calling the xa_open()XA interface routine. When the communication finishes, theTM closes the channel by calling xa_close(). For more infor- mation on opening and closingRMs, see X/Open DistributedTP: TheXA Specification.
The Transaction Manager
Heuristic Decisions
If anRM aborts the work it is doing for a transaction branch during the precommit phase (phase one), theTM aborts the transaction branch during the postdecision phase (phase two). When the transaction branch is aborted, allRMs are in a consistent state.
However, an RM might make a heuristic decision during the postdecision phase. That is, anRMthat is prepared to commit a transaction branch can decide to commit or abort its work independently of theTM. If this occurs, when theTM tells theRM to complete the transaction branch during the postdecision phase, theRM reports that the transaction branch was either committed or aborted.
When a participatingRM makes a heuristic decision and reports its decision to theTM, the TMreturns an error message to the application. The actual text of the error message isTM dependent. It is probably similar to one of the following error messages:
■ Due to a heuristic decision, the work done for the specifiedGTRID was aborted.
■ Due to some failure, the work done for the specifiedGTRID might have been heuristically completed.
■ Due to a heuristic decision, the work done for the specifiedGTRID was partially committed and partially aborted.
In the first case, the global transaction was aborted. When the state that the RMreports matches the state that theTM requires, no problem exists because the transaction branch was completed (either aborted or committed by all RMs) successfully. This response means that the global system is still consistent, and no further problem exists.
In the second and third cases, however, theTMerror messages indicate that the transaction state is unknown or mixed. (A mixed state can occur if the transaction is partially committed and partially aborted due to a heuristic decision made by anRM.) When the state that theRMreports does not match the state theTMwants, the global system is now inconsistent. The system administrator must bring the system back to a consistent state. Because