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

148 lines
9.8 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="Scenario: Commitment control" />
<meta name="abstract" content="The JKL Toy Company uses commitment control to protect the database records for manufacturing and inventory. This scenario shows how JKL toy company uses commitment control to transfer a part from its inventory department to its manufacturing department." />
<meta name="description" content="The JKL Toy Company uses commitment control to protect the database records for manufacturing and inventory. This scenario shows how JKL toy company uses commitment control to transfer a part from its inventory department to its manufacturing department." />
<meta name="DC.Relation" scheme="URI" content="rzakjscenario.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakjdesc_2.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzaki/rzakijournalscenario.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="rzakjcommitscenario" />
<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>Scenario: Commitment control</title>
</head>
<body id="rzakjcommitscenario"><a name="rzakjcommitscenario"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Scenario: Commitment control</h1>
<div><p>The JKL Toy Company uses commitment control to protect the database
records for manufacturing and inventory. This scenario shows how JKL toy company
uses commitment control to transfer a part from its inventory department to
its manufacturing department.</p>
<p>The Scenario: Journal management includes a description of JKL Toy Company's
network environment. The scenario that follows shows how commitment control
works on its production server, JKLPROD.</p>
<p>This scenario illustrates the advantages of using commitment control in
two examples. The first example shows how the company's inventory program,
Program A, might work without commitment control, and the possible problems
that can occur. The second example shows how the program works with commitment
control.</p>
<p>JKL Toy Company uses an inventory application program, Program A, on its
server JKLPROD. Program A uses two records. One record tracks items that are
stored in the stock room. Another record keeps track of items that are removed
from the stock room, and used in production.</p>
<div class="section" xml:lang="en-us" id="rzakjcommitscenario__progcommitwocontrol"><a name="rzakjcommitscenario__progcommitwocontrol"><!-- --></a><h4 class="sectiontitle">Program A without
commitment control</h4><p>Assume that the following application program
does not use commitment control. The system locks records read for updating.
The following steps describe how the application program tracks a diode as
it is removed from the stock room and transferred to checking account:</p>
<ul><li>Program A locks and retrieves the stock room record. (This action might
require a wait if the record is locked by another program.)</li>
<li>Program A locks and retrieves the production record. (This might also
require a wait.) Program A now has both records locked, and no other program
can change them.</li>
<li>Program A updates the stock room record. This causes the record to be
released so it is now available to be read for update by any other program.</li>
<li>Program A updates the production record. This causes the record to be
released so it is now available to be read for update by any other program.</li>
</ul>
<p>Without using commitment control, a problem needs to be solved to
make this program work properly in all circumstances. For example, a problem
occurs if program A does not update both records because of a job or system
failure. In this case, the two files are not consistent -- diodes are removed
from the stock room record, but they are not added to the production record.
Using commitment control allows you to ensure that all changes involved in
the transaction are completed, or that the files are returned to their original
state if the processing of the transaction is interrupted.</p>
</div>
<div class="section" xml:lang="en-us" id="rzakjcommitscenario__progcommitwcontrol"><a name="rzakjcommitscenario__progcommitwcontrol"><!-- --></a><h4 class="sectiontitle">Program A with commitment
control</h4><p>If commitment control is used, the preceding example is
changed as follows:</p>
<ol><li>Commitment control is started.</li>
<li>Program A locks and retrieves the stock room record. (This action can
require a wait if the record is locked by another program.)</li>
<li>Program A locks and retrieves the production record. (This can also require
a wait.) Program A now has both records locked, and no other program can change
them.</li>
<li>Program A updates the stock room record, and commitment control keeps
the lock on the record.</li>
<li>Program A updates the production record, and commitment control keeps
the lock on the record.</li>
<li>Program A commits the transaction. The changes to the stock room record
and the production record are made permanent in the files. The changes are
recorded in the journal, which assumes they will appear on disk. Commitment
control releases the locks on both records. The records are now available
to be read for update by any other program.</li>
</ol>
<p>Because the locks on both records are kept by commitment control until
the transaction is committed, a situation cannot arise in which one record
is updated and the other is not. If a routing step or system failure occurs
before the transaction is committed, the system removes (rolls back) the changes
that have been made so that the files are updated to the point where the last
transaction was committed.</p>
<p>For each routing step in which files are
to be under commitment control, the steps shown in the following figure occur:</p>
<br /><img src="rzakj506.gif" alt="Steps under commitment control" /><br /><p>The operations that are performed under commitment control are
journaled to the journal. The start commitment control journal entry appears
after the first file open entry under commitment control. This is because
the first file open entry determines what journal is used for commitment control.
The journal entry from the first open operation is then used to check subsequent
open operations to ensure that all files are using the same journal.</p>
<p>When
a job failure or system failure occurs, the resources under commitment control
are updated to a commitment boundary. If a transaction is started but is not
completed before a routing step ends, that transaction is rolled back by the
system and does not appear in the file after the routing step ends. If the
system abnormally ends before a transaction is completed, that transaction
is rolled back by the system and does not appear in the file after a subsequent
successful initial program load (IPL) of licensed internal code. Anytime a
rollback occurs, reversing entries are placed in the journal.</p>
<p>For example,
assume that JKL company has 100 diodes in stock. Manufacturing takes out 20
from stock, for a new balance of 80. The database update causes both before-image
(100) and after-image (80) journal entries.</p>
<p>Assume the system abnormally
ended after journaling the entries, but before reaching the commitment point
or rollback point. After the IPL, the system reads the journal entry and updates
the corresponding database record. This update produces two journal entries
that reverse the update: the first entry is the before-image (80) and the
second entry is the after-image (100).</p>
<p>When the IPL is successfully
completed after the abnormal end, the system removes (or rolls back) any database
changes that are not committed. In the preceding example, the system removes
the changes from the stock room record because a commit operation is not in
the journal for that transaction. In this case, the before-image of the stock
room record is placed in the file. The journal contains the rolled back changes,
and an indication that a rollback operation occurred.</p>
</div>
</div>
<div>
<ul class="ullinks">
<li class="ulchildlink"><strong><a href="rzakjdesc_2.htm">Image description</a></strong><br />
The image shows the steps that occur for each routing step in which files are to be under commitment control.</li>
</ul>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjscenario.htm" title="You can read scenarios and examples in this topic to see how one company sets up commitment control. Read code examples for programs that use commitment control.">Scenarios and examples: Commitment control</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="../rzaki/rzakijournalscenario.htm">Scenario: Journal management</a></div>
</div>
</div>
</body>
</html>