148 lines
9.8 KiB
HTML
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>
|