Quick Beginnings

Participation in the Two-Phase Commit Process

This section describes the roles played by systems that take part in SPM scenarios.

Application Requester

DB2 Connect assumes the syncpoint model defined by DRDA where only the application requester can initiate a commit. For this reason, syncpoint coordinator functions are included in the DB2 product that is installed at DB2 clients and servers since Version 2.1.1.

The role of the coordinator at an application requester is as follows:

1. It registers the DUOW request with a transaction manager.

2. It delegates further coordination of the DUOW to the transaction manager and the SPM.

Transaction Manager

Distributed units of work must always be registered with a transaction manager. This is done by the coordinator at the application requester. The transaction manager is responsible for:

1. Preserving the integrity of DUOW requests.

2. Providing registration, logging, and decision-making services for DUOW requests.

3. Guaranteeing the integrity of the results of the DUOW.

The SPM is always a partner with a transaction manager, which is assumed to be at an application requester. The transaction manager can be any of the following:

• A DB2 client/server DUOW TM
• An XA-compliant TM, such as CICS for AIX
• A DB2 for OS/390, DB2 for MVS/ESA, or DB2/400 application requester
• A host-based TP Monitor such as CICS Transaction Server for OS/390.

Notes:

1. For AIX and OS/2, earlier DRDA2 support in Transaction Processing Monitors via the Encina Peer-to-Peer Communications gateway has been replaced by the SPM function provided with DB2 Connect Enterprise Edition Version 5.0.

2. Two-phase commit is not supported through the SPM with the Tuxedo(**) Transaction Manager.

Syncpoint Manager

The SPM can serve as:

• The LU 6.2 coordinator on behalf of application requesters, the transaction manager database, and DRDA2 application servers. This is the case when you connect from a DB2 Universal Database client to a DRDA server, such as DB2 for OS/390, through DB2 Connect.
• An LU 6.2 participant on behalf of DB2 Universal Database servers or DB2 Common servers. This is the case when you connect from a DRDA Application requester, such as DB2 for OS/390, to a DB2 Universal Database server through a DB2 Universal Database server that has the SPM operational.

For example, when an application issues a commit, it is the transaction manager that controls the ultimate success or failure of the commit on behalf of the application, but it is the SPM that propagates the unit of work decision to DRDA2 application servers involved in the unit of work.

The SPM is an independent logical unit and it communicates with DRDA servers using APPC protocols. However, communications from DB2 clients to DB2 Connect/SPM gateways or from a DB2 Universal Database/SPM server to remote DB2 Universal Database servers can use any protocol supported by DB2 (APPC, IPX, Named Pipes, NETBIOS, or TCP/IP, depending on your workstation's operating system).

Two-phase Commit Scenario

Figure 20 illustrates a typical DUOW scenario. In this example the sequence of events is as follows:

1. The coordinator at Client A registers automatically with the Transaction Manager database at Server B, using TM_DATABASE=TMB.

2. The application requester at Client A issues a DUOW request to Servers C and E. For example, the following REXX script illustrates this:

   /**/
    'set DB2OPTIONS=+c'   /* in order to turn off autocommit */
    
    'db2 set client connect 2 syncpoint twophase'
    
    'db2 connect to DBC user USERC using PASSWRDC'
    'db2 create table twopc (title varchar(50) artno smallint not null)'
    'db2 insert into twopc (title,artno) values("testCCC",99)'
    
    'db2 connect to DBE user USERE using PASSWRDE'
    'db2 create table twopc (title varchar(50) artno smallint not null)'
    'db2 insert into twopc (title,artno) values("testEEE",99)'
    
    'commit'
    
    exit (0);
   

3. When the commit is issued, the coordinator at the application requester sends prepare requests to the SPM for the updates requested at servers C and E.

4. The SPM is running on Server D, as part of DB2 Connect, and it sends the prepare requests to servers C and E.

5. Servers C and E in turn acknowledge the prepare requests.

6. The SPM sends back an acknowledgement to the coordinator at the application requester.

7. The coordinator at the application requester sends a request to the transaction manager at Server B for the servers that have acknowledged, and the transaction manager decides whether to commit or roll-back.

8. The transaction manager logs the commit decision, and the updates are guaranteed from this point.

9. The coordinator issues commit requests, which are processed by the SPM, and forwarded to servers C and E, as were the prepare requests.

10. Servers C and E commit and report success to the SPM.

11. SPM then returns the commit result to the coordinator, which updates the TMB with the commit results.

Figure 20. Two-phase Commit RDBMS Scenario

[ DB2 List of Books | Search the DB2 Books ]