137 lines
9.8 KiB
HTML
137 lines
9.8 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="Commitment definition for two-phase commit: Not wait for outcome" />
|
||
|
|
<meta name="abstract" content="When a communication or system failure occurs during a commit operation so that resynchronization is required, the default is to wait until the resynchronization is finished before the commit operation completes." />
|
||
|
|
<meta name="description" content="When a communication or system failure occurs during a commit operation so that resynchronization is required, the default is to wait until the resynchronization is finished before the commit operation completes." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjcommitdefs_tp.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/QTNCHGCO.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjstates.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjcommiterror.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="rzakjnowaitoutcome" />
|
||
|
|
<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>Commitment definition for two-phase commit: Not wait for outcome</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakjnowaitoutcome"><a name="rzakjnowaitoutcome"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Commitment definition for two-phase commit: Not wait for outcome</h1>
|
||
|
|
<div><p>When a communication or system failure occurs during a commit operation
|
||
|
|
so that resynchronization is required, the default is to wait until the resynchronization
|
||
|
|
is finished before the commit operation completes.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> The Not wait for outcome option does not apply if you are using a DRDA<sup>®</sup> distributed
|
||
|
|
unit of work over TCP/IP connection. DRDA distributed unit of work over TCP/IP
|
||
|
|
connections never waits for outcome.</div>
|
||
|
|
<p>Consider changing this behavior if the following conditions are true:</p>
|
||
|
|
<ul><li>The applications that participate are independent of each other.</li>
|
||
|
|
<li>Your program logic does not need the results of previous transactions
|
||
|
|
to ensure that your database files remain synchronized.</li>
|
||
|
|
</ul>
|
||
|
|
<p>After you start commitment control, you can use the Change Commitment Options
|
||
|
|
(QTNCHGCO) API to specify that the commitment definition does not wait for
|
||
|
|
the outcome of resynchronization. If you specify N (No) for the <samp class="codeph">Wait
|
||
|
|
for outcome</samp> option, the system uses a database server job (QDBSRVnn)
|
||
|
|
to handle resynchronization asynchronously.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> These database server jobs are started during the IPL process. If you
|
||
|
|
change the options for commitment control, this has no effect on the number
|
||
|
|
of jobs that the system starts.</div>
|
||
|
|
<p>This topic only refers to two values for the resolved <samp class="codeph">Wait for
|
||
|
|
outcome</samp> option, Y (Yes) and N (No). There are actually two more values
|
||
|
|
that you can specify, L (Yes or Inherit from Initiator) and U (No or Inherit
|
||
|
|
from Initiator). When you use these values, the actual value used during each
|
||
|
|
commit operation is resolved to Yes or No by the system. The QTNCHGCO (Change
|
||
|
|
Commitment Options) API topic has more details about these values.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> The initiator's value can only be inherited by an agent if both the
|
||
|
|
initiator and the agent support presumed abort.</div>
|
||
|
|
<p>The <samp class="codeph">wait for outcome</samp> (WFO) option does not affect normal,
|
||
|
|
error-free commit processing. If an error occurs, the WFO option determines
|
||
|
|
whether the application waits for resynchronization or not, with the following
|
||
|
|
conditions:</p>
|
||
|
|
<ul><li>If the resolved WFO option is Y (Yes), the application waits for the result
|
||
|
|
of the resynchronization. </li>
|
||
|
|
<li>If the resolved WFO option is N (No) and a communication failure occurs
|
||
|
|
during the prepare wave or rollback of a location that supports presumed abort
|
||
|
|
protocols, no resynchronization is performed and the commitment definition
|
||
|
|
is rolled back.</li>
|
||
|
|
<li>If the commitment definition is in doubt (transaction state is prepared
|
||
|
|
or Last Agent Pending), the application will wait for the result of the resynchronization
|
||
|
|
regardless of the resolved WFO value.</li>
|
||
|
|
<li>If the resolved WFO option is N and neither one of conditions two or three
|
||
|
|
is true, the system attempts to resynchronize once. If it is not successful,
|
||
|
|
the system signals STATUS message CPF83E6 to the application to indicate that
|
||
|
|
resynchronization is in progress. <p>Because CPF83E6 is a STATUS message,
|
||
|
|
it only has an effect if the application is monitoring for it. Normally, your
|
||
|
|
application can treat this message as an informational message. The systems
|
||
|
|
that are participating in the transaction attempt to resynchronize the transaction
|
||
|
|
until the failure is repaired. These subsequent resynchronization attempts
|
||
|
|
are performed in the database server jobs. If a subsequent resynchronization
|
||
|
|
attempt that is performed in a database server job fails, the message CPI83D0
|
||
|
|
is sent to QSYSOPR.</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Wait for outcome value: Yes</h4><p>In the following figure,
|
||
|
|
the commitment definition for the initiator (I) uses the default value of
|
||
|
|
Y (Yes) for the <samp class="codeph">Wait for outcome</samp> option. When communications
|
||
|
|
between TM-I and TM-A is lost, both application A and application I wait until
|
||
|
|
the transaction is resynchronized.</p>
|
||
|
|
<br /><img src="rzakj517.gif" alt="Flow of wait for outcome-Yes" /><br /></div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Wait for outcome value: No</h4><p>In the following figure,
|
||
|
|
the commitment definition for the initiator has the resolved WFO set to N
|
||
|
|
(No). TM-A meets condition 3 in the preceding list, while TM-I meets condition
|
||
|
|
4. Control is returned to application I after one attempt to resynchronize
|
||
|
|
with TM-A. A database server job attempts to resynchronize. Application I
|
||
|
|
never receives the return indicator when the commit request has completed
|
||
|
|
successfully. Control is not returned to the agent application (A) until after
|
||
|
|
communications is reestablished. This depends on the timing of the failure.
|
||
|
|
In this case, the communications failure occurs before the commit message
|
||
|
|
is received from the initiator, leaving TM-A in doubt as to whether to commit
|
||
|
|
or rollback. When the transaction manager is in doubt, it retains control
|
||
|
|
until the resynchronization is completed, regardless of the resolved WFO value
|
||
|
|
at that system.</p>
|
||
|
|
<p>If you want the applications at all systems to continue
|
||
|
|
before resynchronization completes, you must either change the resolved WFO
|
||
|
|
option to N (No) on all systems, or set the initiator to N and the rest of
|
||
|
|
the systems to U (No or Inherit from Initiator). But remember that the resolved
|
||
|
|
WFO option is ignored when the transaction manager is in doubt as to whether
|
||
|
|
to commit or rollback, and always waits until resynchronization completes
|
||
|
|
before returning control.</p>
|
||
|
|
<br /><img src="rzakj513.gif" alt="Flow of wait for outcome-No" /><br /><p>When a connection is made to a remote relational
|
||
|
|
database, and no protected conversations have already been started, the system
|
||
|
|
implicitly changes the <samp class="codeph">Wait for outcome</samp> value to N. The reason
|
||
|
|
for this is that the performance of commit operations is improved when the <samp class="codeph">Wait
|
||
|
|
for outcome</samp> value is N and the remote system supports presumed abort.
|
||
|
|
This implicit change of the <samp class="codeph">Wait for outcome</samp> value is only
|
||
|
|
performed for DRDA and
|
||
|
|
DDM applications. APPC applications use the default <samp class="codeph">Wait for outcome</samp> value
|
||
|
|
of Y unless they call the QTNCHGCO API to change it.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjcommitdefs_tp.htm" title="After you start commitment control, you can use the Change Commitment Options (QTNCHGCO) API to change the commitment options for your transaction.">Commitment definitions for two-phase commitment control</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzakjstates.htm" title="A commitment definition is established at each location that is part of the transaction program network. For each commitment definition, the system keeps track of the state of its current transaction and previous transaction.">States of the transaction for two-phase commitment control</a></div>
|
||
|
|
<div><a href="rzakjcommiterror.htm" title="When you use commitment control, it is important to understand which conditions cause errors and which do not.">Commitment control errors</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relref"><strong>Related reference</strong><br />
|
||
|
|
<div><a href="../apis/QTNCHGCO.htm">Change Commitment Options (QTNCHGCO) API</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|