Filter
Top Products
Chapter 8. Enabling Multisite Updates (Two-Phase Commit)
This chapter provides an overview of the multisite update function as it
applies to scenarios that involve host and AS/400 database servers. It
describes products and components needed to implement PC, UNIX and web
applications that update multiple DB2 databases in the same transaction.
Multisite update, also known as Distributed Unit of Work (DUOW) and
Two-Phase commit, is a function that enables your applications to update data
in multiple remote database servers with guaranteed integrity. A good
example of a multisite update is a banking transaction that involves the
transfer of money from one account to another in a different database server.
In such a transaction it is critical that updates that implement debit operation
on one account do not get committed unless updates required to process
credit to the other account are committed as well. The multisite update
considerations apply when data representing these accounts is managed by
two different database servers.
DB2 products provide comprehensive support for multisite update. This
support is available for applications developed using regular SQL as well as
applications that utilize Transaction Monitor products that implement X/Open
XA interface specification. Examples of such Transaction Monitor products
include IBM TxSeries (CICS and Encina), Message and Queuing Series,
Component Broker Series, San Francisco Project as well as Microsoft
Transaction Server (MTS), BEA Tuxedo, NCR TopEnd and several others.
There are different setup requirements depending on whether native SQL
multisite update or TP Monitor multisite update is used.
Both the native SQL and TP Monitor multisite update programs must be
precompiled with the CONNECT 2 SYCNCPOINT TWOPHASE options. Both can use
the SQL Connect statement to indicate which database they want to be used
for the SQL statements that follow. If there is no TP Monitor to tell DB2 it is
going to coordinate the transaction (as indicated by DB2 receiving the xa_open
calls from the TP monitor to establish a database connection), then the DB2
software will be used to coordinate the transaction.
When using TP monitor multisite update, the application must request
commit or rollback by using the TP monitor’s API, e.g. CICS SYNCPOINT,
Encina Abort(), MTS SetAbort(). When using native SQL multisite update,
the normal SQL COMMIT and ROLLBACK must be used.
© Copyright IBM Corp. 1993, 1999 97