320 lines
21 KiB
HTML
320 lines
21 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="XA transaction support for commitment control" />
|
||
|
|
<meta name="abstract" content="DB2 Universal Database (UDB) for iSeries can participate in X/Open global transactions." />
|
||
|
|
<meta name="description" content="DB2 Universal Database (UDB) for iSeries can participate in X/Open global transactions." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjconcepts.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjconsidxa.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="http://www.opengroup.org" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjthreadscoped.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjheuristic.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzakjxatransaction" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>XA transaction support for commitment control</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakjxatransaction"><a name="rzakjxatransaction"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">XA transaction support for commitment control</h1>
|
||
|
|
<div><p>DB2
|
||
|
|
Universal Database™ (UDB) for iSeries™ can participate in X/Open global
|
||
|
|
transactions. </p>
|
||
|
|
<p> The Open Group has defined an industry-standard model
|
||
|
|
for transactional work that allows changes made against unrelated resources
|
||
|
|
to be part of a single global transaction. An example of this is changes to
|
||
|
|
databases that are provided by two separate vendors. This model is called
|
||
|
|
the <em>X/Open Distributed Transaction Processing</em> model.</p>
|
||
|
|
<p>The following publications describe the X/Open Distributed Transaction
|
||
|
|
Processing model in detail:</p>
|
||
|
|
<ul><li><em>X/Open Guide</em>, February 1996, "Distributed Transaction Processing:
|
||
|
|
Reference Model, Version 3" (ISBN:1-85912-170-5, G504), The Open Group.</li>
|
||
|
|
<li><em>X/Open CAE Specification</em>, December 1991, "Distributed Transaction
|
||
|
|
Processing: The XA Specification" (ISBN:1-872630-24-3, C193 or XO/CAE/91/300),
|
||
|
|
The Open Group.</li>
|
||
|
|
<li><em>X/Open CAE Specification</em>, April 1995, "Distributed Transaction
|
||
|
|
Processing: The TX (Transaction Demarcation) Specification" (ISBN:1-85912-094-6,
|
||
|
|
C504), The Open Group.</li>
|
||
|
|
</ul>
|
||
|
|
<p>Be familiar with the information in these books, particularly the XA Specification,
|
||
|
|
before attempting to use the XA transaction support provided by DB2<sup>®</sup> UDB for iSeries.
|
||
|
|
You can find these books at the Open Group Web site.</p>
|
||
|
|
<p>There are five components to the DTP model:</p>
|
||
|
|
<dl><dt class="dlterm">Application Program (AP)</dt>
|
||
|
|
<dd>It implements the required function of the user by specifying a sequence
|
||
|
|
of operations that involves resources such as databases. It defines the start
|
||
|
|
and end of global transactions, accesses resources within transaction boundaries,
|
||
|
|
and normally makes the decision whether to commit or roll back each transaction.</dd>
|
||
|
|
<dt class="dlterm">Transaction Manager (TM)</dt>
|
||
|
|
<dd>It manages global transactions and coordinates the decision to start them
|
||
|
|
and commit them, or roll them back in order to ensure atomic transaction completion.
|
||
|
|
The TM also coordinates recovery activities with the RMs after a component
|
||
|
|
fails.</dd>
|
||
|
|
<dt class="dlterm">Resource Manager (RM)</dt>
|
||
|
|
<dd>It manages a defined part of the computer's shared resources, such as
|
||
|
|
a database management system. The AP uses interfaces defined by each RM to
|
||
|
|
perform transactional work. The TM uses interfaces provided by the RM to carry
|
||
|
|
out transaction completion.</dd>
|
||
|
|
<dt class="dlterm">Communications Resource Manager (CRM)</dt>
|
||
|
|
<dd>It allows an instance of the model to access another instance either inside
|
||
|
|
or outside the current TM domain. CRMs are outside the scope of DB2 UDB for iSeries and
|
||
|
|
are not discussed here.</dd>
|
||
|
|
<dt class="dlterm">Communication Protocol</dt>
|
||
|
|
<dd>The protocols used by CRMs to communicate with each other. This is outside
|
||
|
|
the scope of DB2 UDB
|
||
|
|
for iSeries and
|
||
|
|
is not discussed here.</dd>
|
||
|
|
</dl>
|
||
|
|
<p>The XA Specification is the part of the DTP model that describes a set
|
||
|
|
of interfaces that is used by the TM and RM components of the DTP model. DB2 UDB
|
||
|
|
for iSeries implements
|
||
|
|
these interfaces as a set of UNIX<sup>®</sup> platform-style APIs and exit programs.
|
||
|
|
See <a href="../apis/unix12.htm">XA APIs</a> for detailed
|
||
|
|
documentation of these APIs and for more information about how to use DB2 UDB
|
||
|
|
for iSeries as
|
||
|
|
an RM.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">iSeries Navigator
|
||
|
|
and XA transactions</h4><p>iSeries Navigator supports the management
|
||
|
|
of XA transactions as <dfn class="term">Global Transactions</dfn>.</p>
|
||
|
|
<p>A Global Transaction
|
||
|
|
might contain changes both outside and within DB2 UDB for iSeries. A global transaction is coordinated
|
||
|
|
by an external Transaction Manager using the Open Group XA architecture, or
|
||
|
|
another similar architecture. An application commits or rolls back a global
|
||
|
|
transaction using interfaces provided by the Transaction Manager. The Transaction
|
||
|
|
Manager uses commit protocols defined by the XA architecture, or another architecture,
|
||
|
|
to complete the transaction. DB2 UDB for iSeries acts as an XA Resource Manager
|
||
|
|
when participating in a global transaction. There are two types of global
|
||
|
|
transactions:</p>
|
||
|
|
<ul><li><span class="uicontrol">Transaction-scoped locks:</span> Locks acquired on behalf
|
||
|
|
of the transaction are scoped to the transaction. The transaction can move
|
||
|
|
from one job or thread to another.</li>
|
||
|
|
<li><span class="uicontrol">Job-scoped locks:</span> Locks acquired on behalf of the
|
||
|
|
transaction are scoped to the job. The transaction cannot move from the job
|
||
|
|
that started it.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Considerations for XA transactions</h4><p><img src="./delta.gif" alt="Start of change" />The
|
||
|
|
XA APIs for transaction-scoped locks are recommended for new users of the
|
||
|
|
XA transaction support. The XA APIs for job-scoped locks will continue to
|
||
|
|
be supported, but no longer have any advantages over the XA APIs for transaction-scoped
|
||
|
|
locks. The XA APIs for transaction-scoped locks have fewer restrictions and
|
||
|
|
better performance in the following situations:<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
|
<ul><li>If multiple SQL connections are ever used to work on a single XA transaction
|
||
|
|
branch.</li>
|
||
|
|
<li>If a single SQL connection is used to work on multiple, concurrent XA
|
||
|
|
transaction branches.</li>
|
||
|
|
</ul>
|
||
|
|
<p>In these situations, a separate job must be started to run XA transaction
|
||
|
|
branches when you use the XA APIs for Job Scoped Locks.</p>
|
||
|
|
<p>Understand the
|
||
|
|
following considerations and restrictions before using DB2 UDB for iSeries as a RM. The term <dfn class="term">thread</dfn> refers
|
||
|
|
to either a job that is not thread capable, or a single thread within a thread
|
||
|
|
capable job.</p>
|
||
|
|
<p>The following considerations apply to both transactions
|
||
|
|
with transaction-scoped locks and transactions with job-scoped locks unless
|
||
|
|
noted otherwise.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">DB2 UDB
|
||
|
|
for iSeries considerations</h4><ul><li><img src="./delta.gif" alt="Start of change" />XA transactions against a local database must be performed
|
||
|
|
in jobs that are running in SQL server mode, which means that applications
|
||
|
|
are limited to SQL interfaces when making changes to DB2 UDB for iSeries during an XA transaction. For
|
||
|
|
such transactions, if the <a href="../apis/dxatlopn.htm">xa_open()</a> or
|
||
|
|
db2xa_open() API is used in a job that is not already running in SQL server
|
||
|
|
mode, SQL server mode is implicitly started. <img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
<li> XA transactions against a remote database are required to use SQL server
|
||
|
|
mode when you use the XA APIs for job-scoped locks. However, server mode is
|
||
|
|
optional for XA transactions against a remote database when you use the XA
|
||
|
|
APIs for transaction-scoped locks. Furthermore, changes to DDM files using
|
||
|
|
traditional i5/OS™ database
|
||
|
|
access methods are allowed within XA transactions against a remote database
|
||
|
|
when SQL server mode is not used.</li>
|
||
|
|
<li>Any errors that are detected by DB2 UDB for iSeries during the XA API invocations
|
||
|
|
are reported through return codes by the XA specification. Diagnostic messages
|
||
|
|
are left in the job log when the meaning of the error can not be clear from
|
||
|
|
the return code alone.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Embedded SQL considerations</h4><ul><li><img src="./delta.gif" alt="Start of change" />In order to use a Structured Query Language (SQL) connection
|
||
|
|
for XA transactions, you must use the xa_open() or db2xa_open() application
|
||
|
|
programming interface (API) before the SQL connection is made. The relational
|
||
|
|
database that will be connected to must be passed to the xa_open() or db2xa_open()
|
||
|
|
API by the xainfo parameter. The user profile and password to be used in the
|
||
|
|
job that the connection is routed to might be passed to the xa_open() or db2xa_open()
|
||
|
|
API. If it is not passed, the profile uses the one that was specified or used
|
||
|
|
as the default during the connection attempt.<div class="note"><span class="notetitle">Note:</span> <img src="./delta.gif" alt="Start of change" /> The following
|
||
|
|
consideration applies only to transactions with job-scoped locks.<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
<li>If embedded SQL is used to perform XA transactions, the work performed
|
||
|
|
for each connection is routed to a different job, even if the connections
|
||
|
|
are made in the same thread. This is different than SQL server mode without
|
||
|
|
XA, where work performed for all connections in a single thread is routed
|
||
|
|
to the same job. This is because the XA specification requires a separate
|
||
|
|
prepare, commit or rollback call for each resource manager instance.<div class="note"><span class="notetitle">Note:</span> The
|
||
|
|
following consideration applies only to transactions with job-scoped locks.</div>
|
||
|
|
</li>
|
||
|
|
<li>If embedded SQL is used to perform XA transactions, only one connection
|
||
|
|
per relational database can be made per thread. Whenever the thread is not
|
||
|
|
actively associated with a transaction branch, work requested over one of
|
||
|
|
the thread's connections will cause the RM to use the TM's ax_reg() exit program
|
||
|
|
to determine whether the work is to start, resume or join a transaction branch. <p>If
|
||
|
|
the work is to start a transaction branch, it is performed over that thread's
|
||
|
|
connection to the corresponding relational database.</p>
|
||
|
|
<p>If the work is
|
||
|
|
to join a transaction branch, it is rerouted over the connection to the corresponding
|
||
|
|
relational database that was made in the thread that started the transaction
|
||
|
|
branch. Note that the system does not enforce that the user profile for that
|
||
|
|
connection is the same as the one for the connection of the joining thread.
|
||
|
|
The TM is responsible to ensure that this is not a security concern. Typical
|
||
|
|
TMs use the same user profile for all connections. This user profile is authorized
|
||
|
|
to all data that is managed by the TM. Further security of access to this
|
||
|
|
data is managed by the TM or AP instead of using the standard iSeries security
|
||
|
|
techniques.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> <img src="./delta.gif" alt="Start of change" /> The following consideration applies only
|
||
|
|
to transactions with job-scoped locks.<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
</li>
|
||
|
|
<li>If the work is to resume a transaction branch, the connection that is
|
||
|
|
used depends on whether the suspended transaction branch association was established
|
||
|
|
by starting or joining the transaction branch. <p>Subsequent work is performed
|
||
|
|
over the same connection until the db2xa_end() API is used to suspend or end
|
||
|
|
the thread's association with that transaction branch.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">CLI considerations</h4><ul><li>If the CLI is used to perform XA transactions, more than one connection
|
||
|
|
might be made in the same thread after the db2xa_open() API is used. The connections
|
||
|
|
can be used in other threads to perform XA transactions, as long as those
|
||
|
|
other threads first use the db2xa_open() API with the same xainfo parameter
|
||
|
|
value.<div class="note"><span class="notetitle">Note:</span> The following consideration applies only to transactions with
|
||
|
|
job-scoped locks.</div>
|
||
|
|
</li>
|
||
|
|
<li>If the CLI is used to perform XA transactions, the connection that is
|
||
|
|
used to start a transaction branch must be used for all work on that transaction
|
||
|
|
branch. If another thread is to join the transaction branch, the connection
|
||
|
|
handle for the connection used to start the transaction branch must be passed
|
||
|
|
to the joining thread so that it can perform work over that same connection.
|
||
|
|
Likewise, if a thread is to resume the transaction branch, the same connection
|
||
|
|
must be used. <p>Because CLI connection handles cannot be used in a different
|
||
|
|
job, the join function is limited to threads running in the same job that
|
||
|
|
started the transaction branch when the CLI is used.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Remote relational database considerations</h4><div class="note"><span class="notetitle">Note:</span> These
|
||
|
|
considerations for a remote relational database apply only to transactions
|
||
|
|
with job-scoped locks.</div>
|
||
|
|
<ul><li>XA connections to a remote relational database are supported only if the
|
||
|
|
relational database resides on a system that supports Distributed Unit of
|
||
|
|
Work (DUW) DRDA<sup>®</sup> connections.
|
||
|
|
This includes iSeries systems
|
||
|
|
that run DRDA over
|
||
|
|
SNA LU6.2 conversations, or that use V5R1 or later when running DRDA using TCP/IP
|
||
|
|
connections. This also includes non-iSeries systems that support DRDA over SNA
|
||
|
|
LU6.2 or that support the XA protocol using DRDA over TCP/IP</li>
|
||
|
|
<li>Before using the XA join function, the db2xa_open() API must be used in
|
||
|
|
the joining thread. The same relational database name and RMID must be specified
|
||
|
|
on the db2xa_open() API in both the thread that started the transaction branch
|
||
|
|
and the joining thread. If the transaction branch is active when a join is
|
||
|
|
attempted, the joining thread is blocked. The joining thread remains blocked
|
||
|
|
until the active thread suspends or ends its association with the transaction
|
||
|
|
branch.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Recovery consideration</h4><ul><li>The manual heuristic commit and rollback support that is provided for
|
||
|
|
all commitment definitions can be used if it becomes necessary to force a
|
||
|
|
transaction branch to commit or roll back while it is in a prepared state.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Transaction branch considerations</h4><ul><li>Information about XA transaction branches is shown as part of the commitment
|
||
|
|
control information displayed by iSeries Navigator and the Work with Job
|
||
|
|
(WRKJOB), Display Job (DSPJOB), and Work with Commitment Definition (WRKCMTDFN)
|
||
|
|
commands. The TM name, transaction branch state, transaction identifier and
|
||
|
|
branch qualifier are all shown. The commitment definitions related to all
|
||
|
|
currently active XA transactions can be displayed by using the command <samp class="codeph">WRKCMTDFN
|
||
|
|
JOB(*ALL) STATUS(*XOPEN)</samp> or by displaying the <span class="uicontrol">Global Transactions</span> in iSeries Navigator.<div class="note"><span class="notetitle">Note:</span> The
|
||
|
|
following item applies only to transactions with job-scoped locks.</div>
|
||
|
|
</li>
|
||
|
|
<li>If an association between a thread and an existing transaction branch
|
||
|
|
is suspended or ended using the db2xa_end() API, the thread might start a
|
||
|
|
new transaction branch. If the connection used to start the new transaction
|
||
|
|
branch was used earlier to start a different transaction branch and the thread's
|
||
|
|
association with that transaction branch has been ended or suspended by the
|
||
|
|
db2xa_end() API, a new SQL server job might be started. A new SQL server job
|
||
|
|
is needed only if the first transaction branch has not yet been completed
|
||
|
|
by the db2xa_commit() or db2xa_rollback() API. In this case, another completion
|
||
|
|
message SQL7908 is sent to the job log identifying the new SQL server job,
|
||
|
|
just as the connection's original SQL server job was identified when the connection
|
||
|
|
was established. All SQL requests for the new transaction branch are routed
|
||
|
|
to the new SQL server job. When the transaction branch is completed by the
|
||
|
|
db2xa_commit() or db2xa_rollback() API, the new SQL server job is recycled
|
||
|
|
and returned to the prestart job pool.</li>
|
||
|
|
<li><img src="./delta.gif" alt="Start of change" />A transaction branch is marked <tt>Rollback Only</tt> in
|
||
|
|
the following situations only for the XA transactions for job-scoped locks: <ul><li>A thread ends when it is still associated with the transaction branch.
|
||
|
|
This includes a thread ending as the result of process termination.</li>
|
||
|
|
<li>The system fails.</li>
|
||
|
|
</ul>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
<li><img src="./delta.gif" alt="Start of change" />With XA transactions for transaction-scoped locks, a transaction
|
||
|
|
branch is rolled back by the system if any threads are still associated with
|
||
|
|
it when any of the following situations occur: <ul><li>The connection that is related to the transaction branch is ended.</li>
|
||
|
|
<li>The job that started the transaction branch is ended.</li>
|
||
|
|
<li>The system fails. </li>
|
||
|
|
</ul>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> <img src="./delta.gif" alt="Start of change" />The following consideration applies only to transactions
|
||
|
|
with job-scoped locks.<img src="./deltaend.gif" alt="End of change" /></div>
|
||
|
|
<img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
<li>There is one situation where a transaction branch will be rolled back
|
||
|
|
by the system, regardless of whether there are still associated threads. This
|
||
|
|
occurs when the SQL server job that the connection's work is being routed
|
||
|
|
to is ended. This can only happen when the End Job (ENDJOB) CL command is
|
||
|
|
used against that job.</li>
|
||
|
|
<li>A transaction branch is not affected if no threads have an active association
|
||
|
|
with it when any of the following situations occur. The TM can commit or roll
|
||
|
|
back the transaction branch from any thread that has used the xa_open() or
|
||
|
|
db2xa_open() API with the same xainfo parameter value that was specified in
|
||
|
|
the thread that started the transaction branch. <ul><li>The connection that is related to the transaction branch is ended.</li>
|
||
|
|
<li>A thread or job that performed work for the transaction branch uses the
|
||
|
|
xa_close() or db2xa_close() API.</li>
|
||
|
|
<li>The system fails. In this case, the transaction branch is not affected
|
||
|
|
only if it is in prepared state. If it is in idle state, the system rolls
|
||
|
|
it back.</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li><img src="./delta.gif" alt="Start of change" />When the transaction identifier (XID) of two XA transaction
|
||
|
|
branches have the same global transaction identifier (GTRID), but different
|
||
|
|
branch qualifiers (BQUALs), they are said to be <dfn class="term">loosely coupled</dfn>.
|
||
|
|
By default, loosely coupled transaction branches do not share locks. However,
|
||
|
|
when using the XA APIs for transaction-scoped locks, there is an option that
|
||
|
|
allows loosely coupled transactions to share locks.<img src="./deltaend.gif" alt="End of change" /></li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjconcepts.htm" title="This topic provides information to help you understand how commitment control works, how it interacts with your system, and how it interacts with other systems in your network.">Commitment control concepts</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzakjconsidxa.htm" title="In the XA environment, each database is considered a separate resource manager. When a transaction manager wants to access two databases under the same transaction, it must use the XA protocols to perform two-phase commit with the two resource managers.">Considerations for XA transactions</a></div>
|
||
|
|
<div><a href="http://www.opengroup.org" target="_blank">Open Group Web site</a></div>
|
||
|
|
<div><a href="rzakjthreadscoped.htm" title="Commitment definitions with job-scoped locks are normally scoped to an activation group.">SQL server mode and thread-scoped transactions for commitment control</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="reltasks"><strong>Related tasks</strong><br />
|
||
|
|
<div><a href="rzakjheuristic.htm" title="You can find when and how to force a rollback or commit, and when to cancel resynchronization in this topic.">When to force commits and rollbacks and when to cancel resynchronization</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|