ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzakj_5.4.0.1/rzakjsizetrans.htm

97 lines
6.5 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="Manage transaction size" />
<meta name="abstract" content="Another way to minimize record locks is to manage the size of the transaction." />
<meta name="description" content="Another way to minimize record locks is to manage the size of the transaction." />
<meta name="DC.Relation" scheme="URI" content="rzakjoptimize.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakjcommitbatch.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="rzakjsizetrans" />
<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>Manage transaction size</title>
</head>
<body id="rzakjsizetrans"><a name="rzakjsizetrans"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Manage transaction size</h1>
<div><p>Another way to minimize record locks is to manage the size of the
transaction.</p>
<p>For this discussion, a transaction is interactive. (Commitment control
can also be used for batch applications, which often can be considered a series
of transactions.) Many of the same considerations apply to batch applications,
which are discussed in Commitment control for batch applications.</p>
<p>You can lock a maximum of 500 000 000 records during a transaction for
each journal associated with the transaction. You can reduce this limit by
using a Query Options File (QAQQINI). Use the QRYOPTLIB parameter of the Change
Query Attributes (CHGQRYA) command to specify a Query Options File for a job
to use. Use the COMMITMENT_CONTROL_LOCK_LEVEL value in the Query Options File
as the lock limit for the job.</p>
<p>When choosing the lock level for your records, consider the size of your
transactions. Use size to determine how long records are locked before a transaction
ends. You must decide if a commit or rollback operation for commitment control
is limited to a single use of the Enter key, or if the transaction consists
of many uses of the Enter key.</p>
<div class="note"><span class="notetitle">Note:</span> The shorter the transaction, the earlier the job waiting to start save-while-active
checkpoint processing can continue and complete.</div>
<p>For example, for an order entry application, a customer might order several
items in a single order requiring an order detail record and an inventory
master record update for every item in the order. If the transaction is defined
as the entire order and each use of the Enter key orders an item, all records
involved in the order are locked for the duration of the entire order. Therefore,
often used records (such as inventory master records) might be locked for
long periods of time, preventing other work from progressing. If all items
are entered with a single Enter key using a subfile, the duration of the locks
for the entire order is minimized.</p>
<p>In general, the number and duration of locks must be minimized so several
workstation users can access the same data without long waiting periods. You
can do this by not holding locks while the user is entering data on the display.
Some applications might not require more than one workstation user accessing
the same data. For example, in a cash posting application with many open item
records per customer, the typical approach is to lock all the records and
delay them until a workstation user completes posting the cash for a given
receipt.</p>
<p>If the workstation user presses the Enter key several times for a transaction,
it is possible to perform the transaction in a number of segments. For example:</p>
<ul><li>The first segment is an inquiry in which the workstation user requests
the information.</li>
<li>The second segment is a confirmation of the workstation user's intent
to complete the entire transaction.</li>
<li>The third segment is retrieval and update of the affected records.</li>
</ul>
<p>This approach allows record locking to be restricted to a single use of
Enter.</p>
<p>This inquiry-first approach is normally used in applications where a decision
results from information displayed. For example, in an airline reservation
application, a customer might want to know what flight times, connecting flights,
and seating arrangements are available before making a decision on which flight
to take. After the customer makes a decision, the transaction
is entered. If the transaction fails (the flight is now full), the rollback
function can be used and a different request entered. If the records were
locked from the first inquiry until a decision is made, another reservation
clerk would be waiting until the other transaction is complete.</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <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="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakjcommitbatch.htm" title="Batch applications might or might not need commitment control. In some cases, a batch application can perform a single function of reading an input file and updating a master file. However, you can use commitment control for this type of application if it is important to start it again after an abnormal end.">Commitment control for batch applications</a></div>
</div>
</div>
</body>
</html>