120 lines
9.0 KiB
HTML
120 lines
9.0 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: Allow vote read-only" />
|
|
<meta name="abstract" content="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." />
|
|
<meta name="description" content="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." />
|
|
<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="rzakjroles.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjstates.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rzakjoptimize.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="rzakjallowrdonly" />
|
|
<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: Allow vote read-only</title>
|
|
</head>
|
|
<body id="rzakjallowrdonly"><a name="rzakjallowrdonly"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Commitment definition for two-phase commit: Allow vote read-only</h1>
|
|
<div><p>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.</p>
|
|
<p>If the location has no committable changes during a transaction, the transaction
|
|
manager votes read-only during the prepare wave. The location does not participate
|
|
in the committed wave. This improves overall performance because the communication
|
|
flows that normally occur during the committed wave are eliminated during
|
|
transactions in which no updates are made at one or more remote locations.</p>
|
|
<p>After you start commitment control, you can use the Change
|
|
Commitment Options (QTNCHGCO) API to change the <samp class="codeph">Vote read-only permitted</samp> option
|
|
to Y. You might want to do this if the following conditions are true:</p>
|
|
<ul><li>One or more remote systems often do not have any committable changes for
|
|
a transaction.</li>
|
|
<li>A transaction does not depend on where the file cursor (next record) was
|
|
set by the previous transaction. When a location votes read-only, the application
|
|
is never notified if the transaction is rolled back. The location has committed
|
|
any read operations to the database files and, thus, moved the cursor position.
|
|
The position of the file cursor is typically important only if you do sequential
|
|
processing.</li>
|
|
</ul>
|
|
<p>If your commitment definition is set up to allow vote read-only, the application
|
|
waits for the next message flow from another location.</p>
|
|
<p>The <samp class="codeph">Vote read-only permitted</samp> option is intended for applications
|
|
that are client/server in nature. If the purpose of program A is only to satisfy
|
|
requests from program I, not to do any independent work, it is appropriate
|
|
to allow the <samp class="codeph">Vote read-only</samp> option for program A.</p>
|
|
<div class="section" xml:lang="en-us" id="rzakjallowrdonly__flowcommitproc"><a name="rzakjallowrdonly__flowcommitproc"><!-- --></a><h4 class="sectiontitle">Flow of commit processing
|
|
without last agent optimization when agent votes read-only</h4><p>The following
|
|
figure shows the flow of messages among the application programs and the transaction
|
|
managers when an application program issues a commit instruction without last
|
|
agent optimization when the agent votes read-only. Neither the initiator application
|
|
program nor the agent application programs is aware 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="rzakj515.gif" alt="Flow of commit processing without last agent optimization when agent votes read-only" /><br /><p>The following
|
|
list is a description of the events for normal processing without last agent
|
|
optimization when the agent votes read only. 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>If application program A has used the Change Commitment Options API (QTNCHGCO)
|
|
to set the Vote read-only permitted commitment option to Y and no changes
|
|
have been made at the agent during the transaction, the agent (TM-A) responds
|
|
to the initiator (TM-I) with a reset message. There is no committed wave for
|
|
the agent.</li>
|
|
<li>A return is sent to the application program (A) to indicate that the transaction
|
|
is complete at agent TM-A.</li>
|
|
<li>The next time the initiator (TM-I) issues any message to the agent (TM-A),
|
|
either a data flow or a commitment instruction, TM-I causes its current transaction
|
|
ID to be sent with the message. The reason for this is that a new transaction
|
|
ID might have been generated at TM-I if a communications failure had occurred
|
|
between TM-I and another system during the commit operation.</li>
|
|
<li>A return is sent to the application program (A) to indicate that the transaction
|
|
is complete at agent TM-A. The return is delayed until after the next message
|
|
is received because a new transaction ID must be received from TM-I before
|
|
the next transaction can be started by application 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="relconcepts"><strong>Related concepts</strong><br />
|
|
<div><a href="rzakjroles.htm" title="If a commit of a transaction involves more than one resource manager, each resource manager plays a role in the transaction. A resource manager is responsible for committing or rolling back changes made during the transaction.">Roles in commit processing</a></div>
|
|
<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="rzakjoptimize.htm" title="Using commitment control requires resources that can affect system performance. Several factors affect system performance regarding commitment control.">Optimize performance for 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> |