97 lines
6.5 KiB
HTML
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>
|