172 lines
11 KiB
HTML
172 lines
11 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="States of the transaction for two-phase commitment control" />
|
||
|
|
<meta name="abstract" content="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." />
|
||
|
|
<meta name="description" content="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." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjtwophase.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjallowrdonly.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjnowaitoutcome.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjstartcommit.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjcommitrecov.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="rzakjstates" />
|
||
|
|
<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>States of the transaction for two-phase commitment control</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakjstates"><a name="rzakjstates"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">States of the transaction for two-phase commitment control</h1>
|
||
|
|
<div><p>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. </p>
|
||
|
|
<p>The system uses the state to decide whether to commit or roll back if a
|
||
|
|
transaction is interrupted by a communication or system failure. If multiple
|
||
|
|
locations are participating in a transaction, the states of the transactions
|
||
|
|
at each location might be compared to determine the correct action (commit
|
||
|
|
or rollback). This process of communicating between locations to determine
|
||
|
|
the correct action is called <span class="uicontrol">resynchronization</span>.</p>
|
||
|
|
<p>The following table shows:</p>
|
||
|
|
<ul><li>The basic states that might occur during a transaction.</li>
|
||
|
|
<li>Additional states that might occur.</li>
|
||
|
|
<li>Whether a state requires resynchronization if the transaction is interrupted
|
||
|
|
by a communications or system failure. The possible values are: <dl><dt class="dlterm">Not needed</dt>
|
||
|
|
<dd>Each location can make the correct decision independently.</dd>
|
||
|
|
<dt class="dlterm">May be necessary</dt>
|
||
|
|
<dd>Each location can make the correct decision, but the initiator might need
|
||
|
|
to be informed of the decision.</dd>
|
||
|
|
<dt class="dlterm">Required</dt>
|
||
|
|
<dd>The state of each location must be determined before the correct decision
|
||
|
|
can be made.</dd>
|
||
|
|
</dl>
|
||
|
|
</li>
|
||
|
|
<li>Action taken by a communications or system failure.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th valign="top" id="d0e67">State name</th>
|
||
|
|
<th valign="top" id="d0e69">Description</th>
|
||
|
|
<th valign="top" id="d0e71">Resynchronization if the transaction is interrupted</th>
|
||
|
|
<th valign="top" id="d0e73">Action taken by a communications or system failure</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td colspan="4" valign="top" headers="d0e67 d0e69 d0e71 d0e73 "><strong>Basic states during two-phase commit
|
||
|
|
processing:</strong></td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Reset (<strong>RST</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">From the commitment boundary until a program issues a request to commit
|
||
|
|
or roll back.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">Not needed.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">Pending changes are rolled back.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Prepare in Progress (<strong>PIP</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">The initiator has started the prepare wave. All locations have not
|
||
|
|
yet voted.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">Pending changes are rolled back.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Prepared (<strong>PRP</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">This location and all locations further down in the transaction program
|
||
|
|
network have voted to commit. This location has not yet received notification
|
||
|
|
from the initiator to commit.</td>
|
||
|
|
<td valign="top" headers="d0e71 "> Required.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">In doubt. Depends on the results of the resynchronization process.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Commit in Progress (<strong>CIP</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">All locations have voted to commit. The initiator has started the committed
|
||
|
|
wave.</td>
|
||
|
|
<td valign="top" headers="d0e71 "> Required.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">Pending changes are committed. Resynchronization is performed to ensure
|
||
|
|
that all locations have committed. If a heuristic rollback is reported by
|
||
|
|
another location, an error is reported.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Committed (<strong>CMT</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">All agents have committed and returned a reply to this node.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">None.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td colspan="4" valign="top" headers="d0e67 d0e69 d0e71 d0e73 "><strong>Additional states during two-phase
|
||
|
|
commit processing:</strong> </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Last Agent Pending (<strong>LAP</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">If a last agent is selected, this state occurs at the initiator between
|
||
|
|
the PIP state and the CIP state. The initiator has instructed the last agent
|
||
|
|
to commit and has not yet received a response.</td>
|
||
|
|
<td valign="top" headers="d0e71 "> Required.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">In doubt. Depends on the results of the resynchronization process.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 "> Vote-Read-Only (<strong>VRO</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">This agent responded to the prepare wave by indicating that it has
|
||
|
|
no pending changes. If the vote-read-only state is permitted, this agent is
|
||
|
|
not included in the committed wave.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">None.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Rollback Required (<strong>RBR</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">One of the following events occurred: <ul><li>An agent issued a rollback request before the commit operation.</li>
|
||
|
|
<li>A transaction failure has occurred.</li>
|
||
|
|
<li>The QTNRBRQD API was used to place the transaction in a rollback required
|
||
|
|
state.</li>
|
||
|
|
</ul>
|
||
|
|
The transaction program is not allowed to perform any additional changes
|
||
|
|
under commitment control.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">Pending changes are rolled back.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td colspan="4" valign="top" headers="d0e67 d0e69 d0e71 d0e73 "><strong>Conditions that occur because of operator
|
||
|
|
actions or errors:</strong> </td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Forced Rollback</td>
|
||
|
|
<td valign="top" headers="d0e69 ">This location and all locations further down the transaction program
|
||
|
|
network, except the last agent, have been rolled back through operator intervention.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">Pending changes have already been rolled back.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Forced Commit</td>
|
||
|
|
<td valign="top" headers="d0e69 ">This location and all locations further down the transaction program
|
||
|
|
network, except the last agent, have committed through operator intervention.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">Pending changes have already been committed.</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e67 ">Heuristic Mixed (<strong>HRM</strong>)</td>
|
||
|
|
<td valign="top" headers="d0e69 ">Some resource managers have committed. Some have rolled back. Operator
|
||
|
|
intervention was used or a system error occurred. Heuristic mixed does not
|
||
|
|
appear as a status on the commitment definition displays. Notification messages
|
||
|
|
are sent to the operator.</td>
|
||
|
|
<td valign="top" headers="d0e71 ">May be necessary.</td>
|
||
|
|
<td valign="top" headers="d0e73 ">The operator must perform a restore operation at all participating
|
||
|
|
locations to bring the database to a consistent state.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjtwophase.htm" title="Two-phase commitment control ensures that committable resources on multiple systems remain synchronized.">Two-phase commitment control</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzakjallowrdonly.htm" title="Normally, a transaction manager participates in both phases of commit processing. To improve the performance of commit processing, you can set up some or all locations in a transaction to allow the transaction manager to vote read-only.">Commitment definition for two-phase commit: Allow vote read-only</a></div>
|
||
|
|
<div><a href="rzakjnowaitoutcome.htm" title="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.">Commitment definition for two-phase commit: Not wait for outcome</a></div>
|
||
|
|
<div><a href="rzakjstartcommit.htm" title="To start commitment control, use the Start Commitment Control (STRCMTCTL) Command.">Start commitment control</a></div>
|
||
|
|
<div><a href="rzakjcommitrecov.htm" title="When you perform an initial program load (IPL) after your system ends abnormally, the system attempts to recover all the commitment definitions that were active when the system ended.">Commitment control recovery during initial program load after abnormal end</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>
|
||
|
|
</body>
|
||
|
|
</html>
|