Using the peer-to-peer model, all systems are equal until an application program running on a system issues the commit request that begins the syncpoint operation. The fact that any system can initiate the syncpoint operation is an important attribute of the peer-to-peer model.
A good place to begin a description of the peer-to-peer model is with a more detailed description of what happens when the ATM user mentioned earlier requests a transfer of money from a savings account to a checking account. Figure 1 lists the processing steps.
- The ATM user requests a transfer of money from a savings account to a checking account. The savings account database resides on one system (system A), while the checking account database resides on another system (system B).
- The ATM application program (APPL-A) on system A receives the input from the ATM user.
- APPL-A requests that the savings resource manager on system A
subtract the money from the savings database.
APPL-A requests the checking resource manager on system B to add the money to the checking database. To make this request, APPL-A communicates with APPL-B (the part of the ATM application that runs on system B). APPL-B tells the resource manager on system B to add the money to the checking account database.
- APPL-A calls RRS to commit the database changes.
- RRS on system A asks both resource managers (the one on system A and the one on system B) to prepare for the changes.
- Both resource managers indicate to RRS on system A whether or not they can make the changes by voting YES or NO. For this example, assume that both vote YES.
- In response, RRS on system A notifies both resource managers to make the changes permanent, which is called committing the changes.
- The resource managers complete the commit and return OK to RRS on system A.
- RRS on system A issues a return code to APPL-A to indicate that its commit request was successful; the databases have been changed.
As Figure 1 describes, APPL-A must be able to communicate with APPL-B. It is also true, though less obvious in the example, that RRS on system A must be able to communicate with RRS on system B.
Note that the initiating system is the system on which the commit request is first issued. In the example, the initiating system is system A. Every other system (such as system B in the example) is an agent system. The communications resource manager (CRM) that runs on an agent system is called an agent CRM.
Figure 1 presents a high-level example of peer-to-peer processing. To help explain the role of the communications manager, this book uses APPC/MVS as the communications resource manager, but any communications resource manager that implements the peer-to-peer model would perform the same processing. Figure 2 adds communication processing to the high-level example.
- The ATM user requests a transfer of money from a savings account to a checking account. The savings account database resides on one system (system A), while the checking account database resides on another system (system B).
- The ATM application program (APPL-A) on system A receives the input from the ATM user.
- APPL-A requests that the savings resource manager on system A
subtract the money from the savings database.
APPL-A requests the checking resource manager on system B to add the money to the checking database. To make this request, APPL-A communicates with APPL-B (the part of the ATM application that runs on system B). APPL-B tells the resource manager on system B to add the money to the checking account database.
- APPL-A calls RRS to commit the database changes. Because the application on system A requests the commit, system A becomes the initiating system.
- RRS on system A asks both resource managers (the one on system A
and the one on system B) to prepare for the changes:
- RRS on system A collects prepare votes from resource managers on system A. These votes are called local prepare votes.
- RRS on system A tells RRS on system B (the agent system)
to collect prepare votes from resource managers on system B. These
s are vote called distributed prepare votes. To collect these distributed
prepare votes:
- RRS on the initiating system (system A) tells APPC on A to system notify the application on the agent system (system B) of the need to commit the changes. APPC on system A contacts APPC onand APPC system B, on system B tells APPL-B that a commit is needed.
- APPL-B calls RRS on system B, requesting that the changes be committed.
- RRS on system B, the agent system, collects distributed prepare votes from the resource managers on system B.
- Both resource managers indicate to RRS on system A whether or
not they can make the changes by voting YES or NO. For this example,
assume that both vote YES:
- RRS on system A, the initiating system, determines the outcome of the local prepare votes.
- RRS on system B, the agent system, tells RRS on system A the result of the distributed prepare votes, using APPC to communicate with RRS on system A.
RRS on system A, the initiating system, makes the final decision to commit or back out the resource changes, basing the decision on the local prepare votes and the result of the distributed votes. For this example, assume that the overall result is to commit the resource changes.
- In response, RRS on system A notifies both resource managers to
make the changes permanent, which is called committing the changes:
- RRS on the initiating system (system A) tells the resource managers on system A to commit the changes.
- RRS on system A uses APPC to tell RRS on system B, the agent system, that the final decision is to commit the resource changes.
- The resource managers complete the commit and return OK to RRS
on system A:
- The resource managers on system A tell RRS on system A that the commit is complete.
- The resource managers on system B tell RRS on system B that the commit is complete, and RRS on system B uses APPC to tell RRS on system A that the commit is complete on the agent system.
- RRS on system A issues a return code to APPL-A to indicate that its commit request was successful; the databases have been changed.
The initiator is responsible for the overall decision. The agents are responsible for collecting local votes and distributing the decision to the local coordinator (RRS). When APPC/MVS becomes an agent, it informs RRS by taking the distributed syncpoint resource manager (DSRM) role, which makes it responsible for informing RRS of the commit decision.
RRS on each MVS™ system provides the two-phase commit protocol for the resource managers on its system. Each RRS collects the prepare votes from the local resource managers, then returns the collective vote to the DSRM.
When a work request is distributed rather than local, the two-phase commit processing is slightly different: on the agent system, the UR state becomes in-doubt at the end of phase 1. The state remains in-doubt until the initiator collects all the votes and returns a commit or backout signal to the DSRM on the agent system.
Remember that RRS is an exit manager; it drives resource manager exit routines in response to resource recovery events. For example, when an application requests commit, RRS drives the PREPARE and COMMIT exit routines for each resource manager involved.
To put all the pieces together, assume a transaction where a user requests the transfer of money from a checking account to the electric company to pay an electric bill. The actions required to process this sample transaction are:
- The user of a computer connected by a modem to the bank's computer requests transfer of money from a checking account to the electric company to pay an electric bill.
- The bank application program receives the user's input.
Figure 3 shows, for this transaction, the sequence of the following actions, with time moving from left to right, in the two-phase commit protocol with distributed resource recovery. The top lines of the figure show the states for each UR as it moves through the two-phase commit protocol. For more information, see UR states and Two-phase commit protocol.
- The bank application:
- Requests the checking resource manager to subtract the money from the checking database
- Allocates a conversation to the electric company application to receive the money as payment for the electric bill
- The electric company application requests the billing database resource manager to add the money to the user's account.
- The bank application issues a call to RRS 1 to commit the checking database changes.
- RRS 1 asks the checking resource manager to prepare for the changes.
The PREPARE exit routine votes YES.
If any vote is NO, all changes are backed out on all systems.
- RRS 1 also sends a PREPARE signal through APPC/MVS
1 to APPC/MVS 2. In response to the PREPARE signal:
- APPC/MVS 2 informs RRS 2 that it is assuming the role of distributed syncpoint resource manager (DSRM). RRS 2 does not complete the commit; that is, RRS 2 does not drive COMMIT exit routines until told to do so by the DSRM. (This action is related to the processing described for step 10).
- APPC/MVS 2 informs the electric company application that a commit has been requested.
- The electric company application issues a call to RRS 2 to commit the billing database changes.
- RRS 2 asks the billing resource manager to prepare for the changes.
The PREPARE exit routine votes YES.
If any vote is NO, all changes are backed out on all systems.
- The resources are distributed, so RRS 2 cannot make
a unilateral commit; it must synchronize its commit with RRS 1 to
ensure that all changes are made or no changes are made.
Because APPC/MVS 2 took the DSRM role earlier, RRS 2 does not call COMMIT exits. Instead, RRS 2 collects the votes on system 2. If all resource managers vote yes, then the local collective vote is to commit the changes, and RRS 2 tells APPC/MVS 2 to send a REQUEST_COMMIT signal through APPC/MVS 1 to RRS 1.
If any resource manager on the electric company's system (the agent system) votes not to commit the resource, then the local collective vote is NO, and RRS 2 sends a REQUEST_BACKOUT signal.
- RRS 1 notifies the checking resource manager to commit the changes.
The checking resource manager completes the commit and returns OK
to RRS 1.
For a REQUEST_BACKOUT signal, RRS 1 notifies the checking resource manager to backout the changes. The changes are not made.
- RRS 1 notifies APPC/MVS 1 to commit the changes. APPC/MVS 1 sends a COMMITTED signal through APPC/MVS 2 to RRS 2.
- RRS 2 notifies the billing resource manager to commit the changes. The billing resource manager completes the commit and returns OK to RRS 2.
- RRS 2 informs APPC/MVS 2 that RRS 2 has finished its processing for the UR. APPC/MVS 2 sends a FORGET signal through APPC/MVS 1 to RRS 1; the signal means that APPC/MVS 1 can do clean up for the UR.
- RRS 1 has finished its processing for the UR and informs APPC/MVS 1.
- RRS 1 and RRS 2 give return codes to the application programs, indicating that all changes were made in the databases.
At this point, you might want to know more about how RRS uses APPC to communicate across systems. The basic mechanism is the exit routines APPC sets with RRS.
APPC registers with RRS as a resource manager, just like any resource manager. Thus, RRS will drive APPC's PREPARE and COMMIT exit routines when the bank application and the billing application issue their commit requests.
After APPC's PREPARE exit receives the response, the COMMITTED signal described in step 12 is sent by APPC's COMMIT exit routine, which then waits for a response.
After APPC's waiting DISTRIBUTED_SYNCPOINT exit routine receives the response, the FORGET signal described in step 14 is sent by APPC's END_UR exit routine and received by its waiting COMMIT exit.
