133 lines
8.6 KiB
HTML
133 lines
8.6 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="Vote reliable effect on flow of commit processing" />
|
||
|
|
<meta name="abstract" content="Vote reliable is an optimization that improves performance by returning earlier to the initiator application after a commit operation and eliminating one message during a commit operation." />
|
||
|
|
<meta name="description" content="Vote reliable is an optimization that improves performance by returning earlier to the initiator application after a commit operation and eliminating one message during a commit operation." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjcommitdefs_tp.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../apis/QTNCHGCO.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="rzakjvotereliable" />
|
||
|
|
<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>Vote reliable effect on flow of commit processing</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakjvotereliable"><a name="rzakjvotereliable"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Vote reliable effect on flow of commit processing</h1>
|
||
|
|
<div><p>Vote reliable is an optimization that improves performance by returning
|
||
|
|
earlier to the initiator application after a commit operation and eliminating
|
||
|
|
one message during a commit operation. </p>
|
||
|
|
<p>There is no explicit vote reliable optimization for DRDA<sup>®</sup> distributed
|
||
|
|
unit of work over TCP/IP. However, i5/OS™ never requests a reset (forget) confirmation
|
||
|
|
for TCP/IP connections. Therefore, a reset (forget) is always implied for
|
||
|
|
TCP/IP connections.</p>
|
||
|
|
<p>After you start commitment control, you can use the Change Commitment Options
|
||
|
|
(QTNCHGCO) API to change the <samp class="codeph">Accept vote reliable</samp> option
|
||
|
|
to Y.</p>
|
||
|
|
<p>Vote reliable can be thought of as a promise by an agent to its initiator
|
||
|
|
that no heuristic decisions will be made at the agent if communications failure
|
||
|
|
occurs while the agent is in doubt. An agent that is using the vote reliable
|
||
|
|
optimization sends an indicator to the initiator during the prepare wave of
|
||
|
|
the commit. If the initiator is also using the vote reliable optimization,
|
||
|
|
it then sends an indicator to the agent that no reset is required in response
|
||
|
|
to the commit message. This eliminates the reset message, and allows the transaction
|
||
|
|
manager to return to the application at the initiator as soon as the commit
|
||
|
|
message is sent.</p>
|
||
|
|
<p>Consider using the vote reliable optimization if the following conditions
|
||
|
|
are true:</p>
|
||
|
|
<ul><li>It is unlikely that a heuristic decision will be made at an in doubt agent
|
||
|
|
in the event of a systems or communications failure unless the failure cannot
|
||
|
|
be repaired.</li>
|
||
|
|
<li>Your program logic does not need the results of previous transactions
|
||
|
|
to ensure that your database files remain synchronized.</li>
|
||
|
|
</ul>
|
||
|
|
<p>The vote reliable optimization is used by i5/OS only if <em>all</em> the
|
||
|
|
following conditions are true:</p>
|
||
|
|
<ul><li>The initiator and agent locations support the presumed abort level of
|
||
|
|
commitment control.</li>
|
||
|
|
<li>The initiator location accepts the vote reliable
|
||
|
|
indication from the agent. On i5/OS initiators, this depends on the value
|
||
|
|
of two commitment options: <ul><li>The value of the Wait for outcome commitment option must be No (Yes is
|
||
|
|
the default).</li>
|
||
|
|
<li>The value of the Accept vote reliable commitment option must be Yes (Yes
|
||
|
|
is the default).</li>
|
||
|
|
</ul>
|
||
|
|
</li>
|
||
|
|
<li>The agent location votes reliable during the prepare
|
||
|
|
wave. i5/OS agents
|
||
|
|
always vote reliable. This is because heuristic decisions can be made only
|
||
|
|
through a manual procedure that warns of the possible negative side-effects
|
||
|
|
of making a heuristic decision.</li>
|
||
|
|
</ul>
|
||
|
|
<div class="section" xml:lang="en-us" id="rzakjvotereliable__flowcommitprocvotereliableopt"><a name="rzakjvotereliable__flowcommitprocvotereliableopt"><!-- --></a><h4 class="sectiontitle">Flow of
|
||
|
|
commit processing with vote reliable optimization</h4><p>The following
|
||
|
|
figure shows the flow of messages among the application programs and the transaction
|
||
|
|
managers when the vote reliable optimization is used. Both the initiator application
|
||
|
|
program and the agent application programs are unaware of the two-phase commit
|
||
|
|
processing. The numbers in parentheses () in the figure correspond to the
|
||
|
|
numbered items in the description that follows.</p>
|
||
|
|
<br /><img src="rzakj516.gif" alt="Flow of commit processing with vote reliable optimization" /><br /><p>The following
|
||
|
|
list describes the events for normal processing without last agent optimization
|
||
|
|
when the agent votes reliable. This describes a basic flow. The sequence of
|
||
|
|
events can become much more complex when the transaction program network has
|
||
|
|
multiple levels or when errors occur.</p>
|
||
|
|
<ol><li>Application program A does a receive request to indicate that it is ready
|
||
|
|
to receive a request from program I.</li>
|
||
|
|
<li>The initiator application (I) issues a commit instruction.</li>
|
||
|
|
<li>The transaction manager for the initiator (TM-I) takes the role of initiator
|
||
|
|
for this transaction. It starts the prepare wave by sending a prepare message
|
||
|
|
to all the other locations that are participating in the transaction.</li>
|
||
|
|
<li>The transaction managers for every other location take the role of agent
|
||
|
|
(TM-A). The application program A is notified by TM-A that a request to commit
|
||
|
|
has been received. For ICF files, the notification is in the form of the Receive
|
||
|
|
Take Commit (RCVTKCMT) ICF indicator being set on.</li>
|
||
|
|
<li>The application program A responds by issuing a commit instruction (or
|
||
|
|
a rollback instruction). This is the application program's vote.</li>
|
||
|
|
<li>The agent (TM-A) responds to the initiator (TM-I)
|
||
|
|
with a request commit message. i5/OS systems send a vote reliable indicator
|
||
|
|
with the request commit.</li>
|
||
|
|
<li id="rzakjvotereliable__step7"><a name="rzakjvotereliable__step7"><!-- --></a>When the initiator (TM-I) receives all the votes, the TM-I
|
||
|
|
sends a commit message. If the Wait for outcome commitment option is N (No)
|
||
|
|
and the Accept vote reliable commitment option is Y (Yes), a no reset indicator
|
||
|
|
is sent with the commit message. This tells the agent that no reset message
|
||
|
|
is required in response to the commit.</li>
|
||
|
|
<li>The transaction is complete. A return is sent to the application
|
||
|
|
programs (I and A). This return indicates that the commit operation was successful.
|
||
|
|
If a heuristic damage occurs at system A due to a heuristic decision being
|
||
|
|
made before the committed message is received, application I is not informed.
|
||
|
|
Instead, a message is sent to the QSYSOPR message queue. However, application
|
||
|
|
A receives the heuristic damage indication.</li>
|
||
|
|
<li>The next time the agent (TM-A) sends any message to the initiator (TM-I),
|
||
|
|
either a data flow or a commitment instruction, an implied reset indicator
|
||
|
|
is sent with the message to inform TM-I that TM-A completed the commit successfully.
|
||
|
|
The reason for this is that TM-I must retain information about the completed
|
||
|
|
transaction until it has confirmed that TM-A successfully received the commit
|
||
|
|
message in step <a href="#rzakjvotereliable__step7">7</a></li>
|
||
|
|
</ol>
|
||
|
|
</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="relref"><strong>Related reference</strong><br />
|
||
|
|
<div><a href="../apis/QTNCHGCO.htm">Change Commitment Options (QTNCHGCO) API</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|