185 lines
13 KiB
HTML
185 lines
13 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 xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="dc.language" scheme="rfc1766" 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. -->
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-19" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<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="keywords" content="application process, concurrency, recovery,
|
|
activation group, commitment definition, description, rollback, definition" />
|
|
<title>Application processes, concurrency, and recovery</title>
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
|
</head>
|
|
<body>
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
|
|
|
|
|
<a name="appproc"></a>
|
|
<h2 id="appproc"><a href="rbafzmst02.htm#ToC_45">Application processes, concurrency, and recovery</a></h2><a id="idx120" name="idx120"></a><a id="idx121" name="idx121"></a><a id="idx122" name="idx122"></a><a id="idx123" name="idx123"></a>
|
|
<p>All SQL programs execute as part of an <span class="italic">application process</span>. In i5/OS, an application process is called a job. In the case of ODBC,
|
|
JDBC, OLE DB, .NET, and DRDA®, the application process ends when the connection
|
|
ends even though the job they are using does not end and may be reused. An
|
|
application process is made up of one or more activation groups. Each activation
|
|
group involves the execution of one or more programs. Programs run under a
|
|
non-default activation group or the default activation group. All programs
|
|
except those created by ILE compilers run under the default activation group.</p>
|
|
<p>For more information about activation groups, see the book <a href="../books/sc415606.pdf" target="_blank">ILE Concepts</a>
|
|
<img src="wbpdf.gif" alt="Link to PDF" />.</p><a id="idx124" name="idx124"></a>
|
|
<p>An application process that uses commitment control can run with one or
|
|
more commitment definitions. A commitment definition provides a means to scope
|
|
commitment control at an activation group level or at a job level. At any
|
|
given time, an activation group that uses commitment control is associated
|
|
with only one of the commitment definitions.</p>
|
|
<p>A commitment definition can be explicitly started through the Start Commitment
|
|
Control (STRCMTCTL) command. If not already started, a commitment definition
|
|
is implicitly started when the first SQL statement is executed under an isolation
|
|
level different than COMMIT(*NONE). More than one activation group can share
|
|
a job commitment definition.</p>
|
|
<p><a href="rbafzmstappproc.htm#a928">Figure 3</a> shows the relationship of an application process, the
|
|
activation groups in that application process, and the commitment definitions.
|
|
Activation groups A and B run with commitment control scoped to the activation
|
|
group. These activation groups have their own commitment definitions. Activation
|
|
group C does not run with any commitment control and does not have a commitment
|
|
definition.</p>
|
|
<a name="a928"></a>
|
|
<div class="fignone" id="a928"><span class="figcap">Figure 3. Activation Groups without Job Commitment Definition</span>
|
|
<div class="mmobj">
|
|
<img src="rv3f004.gif" alt="Activation Groups without Job Commitment Definition" /></div></div>
|
|
<p><a href="rbafzmstappproc.htm#a931">Figure 4</a> shows an application process, the activation groups
|
|
in that application process, and the commitment definitions. Some of the activation
|
|
groups are running with the job commitment definition. Activation groups A
|
|
and B are running under the job commitment definition. Any commit or rollback
|
|
operation in activation group A or B affects both because the commitment control
|
|
is scoped to the same commitment definition. Activation group C in this example
|
|
has a separate commitment definition. Commit and rollback operations performed
|
|
in this activation group only affect operations within C.</p>
|
|
<a name="a931"></a>
|
|
<div class="fignone" id="a931"><span class="figcap">Figure 4. Activation Groups with Job Commitment Definition</span>
|
|
<div class="mmobj">
|
|
<img src="rv2w931.gif" alt="Activation Groups with Job Commitment Definition" /></div></div>
|
|
<p>For more information about commitment definitions, see the <a href="../rzakj/rzakjcommitkickoff.htm">Commitment control</a> topic.</p>
|
|
<a name="wq16"></a>
|
|
<h3 id="wq16"><a href="rbafzmst02.htm#ToC_46">Locking, commit, and rollback</a></h3>
|
|
<p>Application processes and activation groups that use different commitment
|
|
definitions can request access to the same data at the same time. <span class="italic">Locking</span> is used to maintain data integrity under such conditions. Locking
|
|
prevents such things as two application processes updating the same row of
|
|
data simultaneously.</p>
|
|
<p>The database manager acquires locks to keep the uncommitted changes of
|
|
one activation group undetected by activation groups that use a different
|
|
commitment definition. Object locks and other resources are allocated to an
|
|
activation group. Row locks are allocated to a commitment definition.</p>
|
|
<p>When an activation group other than the default activation group ends <span class="italic">normally</span>, the database manager releases all locks obtained
|
|
by the activation group. A user can also explicitly request that most locks
|
|
be released sooner. This operation is called <span class="italic">commit</span>.
|
|
Object locks associated with cursors that remain open after commit are not
|
|
released.</p><a id="idx125" name="idx125"></a><a id="idx126" name="idx126"></a>
|
|
<p>The recovery functions of the database manager provide a means of backing
|
|
out of uncommitted changes made in a commitment definition. The database manager
|
|
may implicitly back out uncommitted changes under the following situations: </p>
|
|
<ul>
|
|
<li>When the application process ends, all changes performed under the commitment
|
|
definition associated with the default activation group are backed out. When
|
|
an activation group other than the default activation group ends <span class="italic">abnormally</span>, all changes performed under the commitment definition associated
|
|
with that activation group are backed out.</li>
|
|
<li>When using Distributed Unit of Work and a failure occurs while attempting
|
|
to commit changes on a remote system, all changes performed under the commitment
|
|
definition associated with remote connection are backed out.</li>
|
|
<li>When using Distributed Unit of Work and a request to back out is received
|
|
from a remote system because of a failure at that site, all changes performed
|
|
under the commitment definition associated with remote connection are backed
|
|
out.</li></ul>
|
|
<p>A user can also explicitly request that their database changes be backed
|
|
out. This operation is called <span class="italic">rollback</span>.</p>
|
|
<p>Locks acquired by the database manager on behalf of an activation group
|
|
are held until the unit of work is ended. A lock explicitly acquired by a
|
|
LOCK TABLE statement can be held past the end of a unit of work if COMMIT
|
|
HOLD or ROLLBACK HOLD is used to end the unit of work.</p>
|
|
<p>A cursor can implicitly lock the row at which the cursor is positioned.
|
|
This lock prevents: </p>
|
|
<ul>
|
|
<li>Other cursors associated with a different commitment definition from locking
|
|
the same row.</li>
|
|
<li>A DELETE or UPDATE statement associated with a different commitment definition
|
|
from locking the same row.</li></ul>
|
|
<a name="wq17"></a>
|
|
<h3 id="wq17"><a href="rbafzmst02.htm#ToC_47">Unit of work</a></h3>
|
|
<p>A <span class="italic">unit of work</span> (also known as a <span class="italic">logical unit of work</span> or <span class="italic">unit of recovery</span>) is
|
|
a recoverable sequence of operations. Each commitment definition involves
|
|
the execution of one of more units of work. At any given time, a commitment
|
|
definition has a single unit of work.</p>
|
|
<p>A unit of work is started either when the commitment definition is started,
|
|
or when the previous unit of work is ended by a commit or rollback operation.
|
|
A unit of work is ended by a commit operation, a rollback operation, or the
|
|
ending of the activation group. A commit or rollback operation affects only
|
|
the database changes made within the unit of work that the commit or rollback
|
|
ends. While changes remain uncommitted, other activation groups using different
|
|
commitment definitions running under isolation levels COMMIT(*CS), COMMIT(*RS),
|
|
and COMMIT(*RR) cannot perceive the changes. The changes can be backed out
|
|
until they are committed. Once changes are committed, other activation groups
|
|
running in different commitment definitions can access them, and the changes
|
|
can no longer be backed out.</p>
|
|
<p>The start and end of a unit of work defines points of consistency within
|
|
an activation group. For example, a banking transaction might involve the
|
|
transfer of funds from one account to another. Such a transaction would require
|
|
that these funds be subtracted from the first account, and added to the second.
|
|
Following the subtraction step, the data is inconsistent. Only after the funds
|
|
are added to the second account is consistency established again. When both
|
|
steps are complete, the commit operation can be used to end the unit of work.
|
|
After the commit operation, the changes are available to activation groups
|
|
that use different commitment definitions.</p><a id="idx127" name="idx127"></a><a id="idx128" name="idx128"></a>
|
|
<a name="wq18"></a>
|
|
<div class="fignone" id="wq18"><span class="figcap">Figure 5. Unit of Work with a Commit Statement</span>
|
|
<div class="mmobj">
|
|
<img src="rv3f181.gif" alt="Unit of Work with a Commit Statement" /></div></div>
|
|
<a name="wq19"></a>
|
|
<h3 id="wq19"><a href="rbafzmst02.htm#ToC_48">Rolling back work</a></h3>
|
|
<p>The database manager can back out all changes made in a unit of work or only selected
|
|
changes. Only backing out all changes results in a point of consistency.</p>
|
|
<a name="wq20"></a>
|
|
<h4 id="wq20">Rolling back all changes</h4>
|
|
<p>The SQL ROLLBACK statement without the TO SAVEPOINT clause causes a full
|
|
rollback operation. If such a rollback operation is successfully executed, the database manager backs
|
|
out uncommitted changes to restore the data consistency that it assumes existed
|
|
when the unit of work was initiated. That is, the database manager undoes the work, as
|
|
shown in the diagram below:</p>
|
|
<a name="wq21"></a>
|
|
<div class="fignone" id="wq21"><span class="figcap">Figure 6. Unit of Work with a Rollback Statement</span>
|
|
<div class="mmobj">
|
|
<img src="rv3f182.gif" alt="Unit of Work with a Rollback Statement" /></div></div>
|
|
<a name="wq22"></a>
|
|
<h4 id="wq22">Rolling back selected changes using savepoints</h4>
|
|
<p>A <span class="italic">savepoint</span> represents the state of data at some
|
|
particular time during a unit of work. An application process can set savepoints
|
|
within a unit of work, and then as logic dictates, roll back only the changes
|
|
that were made after a savepoint was set. For example, part of a reservation
|
|
transaction might involve booking an airline flight and then a hotel room.
|
|
If a flight gets reserved but a hotel room cannot be reserved, the application
|
|
process might want to undo the flight reservation without undoing any database
|
|
changes made in the transaction prior to making the flight reservation. SQL
|
|
programs can use the SQL SAVEPOINT statement to set savepoints, the SQL ROLLBACK
|
|
statement with the TO SAVEPOINT clause to undo changes to a specific savepoint
|
|
or the last savepoint that was set, and the RELEASE SAVEPOINT statement to
|
|
delete a savepoint.</p>
|
|
<a name="wq23"></a>
|
|
<div class="fignone" id="wq23"><span class="figcap">Figure 7. Unit of Work with a Rollback Statement and a Savepoint Statement</span>
|
|
<div class="mmobj">
|
|
<img src="rv3f202.gif" alt="Unit of work with and Rollback Statement and a Savepoint Statement" /></div></div>
|
|
<hr /><br />
|
|
[ <a href="#Top_Of_Page">Top of Page</a> | <a href="rbafzmstcatalogdef.htm">Previous Page</a> | <a href="rbafzmstthreads.htm">Next Page</a> | <a href="rbafzmst02.htm#wq1">Contents</a> |
|
|
<a href="rbafzmstindex.htm#index">Index</a> ]
|
|
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
|
</body>
|
|
</html>
|