ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaha_5.4.0.1/transiso.htm

172 lines
10 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<?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="Transaction isolation levels" />
<meta name="abstract" content="Transaction isolation levels specify what data is visible to statements within a transaction. These levels directly impact the level of concurrent access by defining what interaction is possible between transactions against the same target data source." />
<meta name="description" content="Transaction isolation levels specify what data is visible to statements within a transaction. These levels directly impact the level of concurrent access by defining what interaction is possible between transactions against the same target data source." />
<meta name="DC.Relation" scheme="URI" content="transactions.htm" />
<meta name="DC.Relation" scheme="URI" content="transaut.htm" />
<meta name="DC.Relation" scheme="URI" content="savepnts.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="transiso" />
<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>Transaction isolation levels</title>
</head>
<body id="transiso"><a name="transiso"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Transaction isolation levels</h1>
<div><p>Transaction isolation levels specify what data is visible to statements
within a transaction. These levels directly impact the level of concurrent
access by defining what interaction is possible between transactions against
the same target data source.</p>
<div class="section"><h4 class="sectiontitle">Database anomalies</h4><p>Database anomalies are generated
results that seem incorrect when looked at from the scope of a single transaction,
but are correct when looked at from the scope of all transactions. The different
types of database anomalies are described as follows:</p>
<ul><li><strong>Dirty</strong> reads occur when: <ol><li>Transaction A inserts a row into a table.</li>
<li>Transaction B reads the new row.</li>
<li>Transaction A rolls back.</li>
</ol>
<p>Transaction B may have done work to the system based on the row
inserted by transaction A, but that row never became a permanent part of the
database.</p>
</li>
<li><strong>Nonrepeatable</strong> reads occur when: <ol><li>Transaction A reads a row.</li>
<li>Transaction B changes the row.</li>
<li>Transaction A reads the same row a second time and gets the new results.</li>
</ol>
</li>
<li><strong>Phantom</strong> reads occur when: <ol><li>Transaction A reads all rows that satisfy a WHERE clause on an SQL query.</li>
<li>Transaction B inserts an additional row that satisfies the WHERE clause.</li>
<li>Transaction A re-evaluates the WHERE condition and picks up the additional
row.</li>
</ol>
</li>
</ul>
<div class="note"><span class="notetitle">Note:</span> DB2<sup>®</sup> for iSeries™ does
not always expose the application to the allowable database anomolies at the
prescribed levels due to its locking strategies.</div>
</div>
<div class="section"><h4 class="sectiontitle">JDBC transaction isolation levels</h4><p>There are five
levels of transaction isolation in the IBM<sup>®</sup> Developer Kit for Java™ JDBC
API. Listed from least to most restrictive, they are as follows:</p>
<dl><dt class="dlterm"><strong>JDBC_TRANSACTION_NONE</strong></dt>
<dd>This is a special constant indicating that the JDBC driver does not support
transactions.</dd>
</dl>
<dl><dt class="dlterm"><strong>JDBC_TRANSACTION_READ_UNCOMMITTED</strong></dt>
<dd>This level allows transactions to see uncommitted changes to the data.
All database anomalies are possible at this level.</dd>
</dl>
<dl><dt class="dlterm"><strong>JDBC_TRANSACTION_READ_COMMITTED</strong></dt>
<dd>This level means that any changes made inside a transaction are not visible
outside it until the transaction is committed. This prevents dirty reads from
being possible.</dd>
</dl>
<dl><dt class="dlterm"><strong>JDBC_TRANSACTION_REPEATABLE_READ</strong></dt>
<dd>This level means that rows that are read retain locks so that another
transaction cannot change them when the transaction is not completed. This
disallows dirty reads and nonrepeatable reads. Phantom read are still possible.</dd>
</dl>
<dl><dt class="dlterm"><strong>JDBC_TRANSACTION_SERIALIZABLE</strong></dt>
<dd>Tables are locked for the transaction so that WHERE conditions cannot
be changed by other transactions that add values to or remove values from
a table. This prevents all types of database anomalies.</dd>
</dl>
<p>The setTransactionIsolation method can be used to change
the transaction isolation level for a connection.</p>
</div>
<div class="section"><h4 class="sectiontitle">Considerations</h4><p>A common misinterpretation is that
the JDBC specification defines the five transactional levels previously mentioned.
It is commonly thought that the TRANSACTION_NONE value represents the concept
of running without commitment control. The JDBC specification does not define
TRANSACTION_NONE in the same manner. TRANSACTION_NONE is defined in the JDBC
specification as a level where the driver does not support transactions and
is not a JDBC-compliant driver. The NONE level is never reported when the
getTransactionIsolation method is called.</p>
<p>The issue is marginally complicated
by the fact that a JDBC driver's default transaction isolation level is defined
by the implementation. The default level of transaction isolation for the
native JDBC driver default transaction isolation level is NONE. This allows
the driver to work with files that do not have journals and you are not required
to make any specifications such as files in the QGPL library.</p>
<p>The native
JDBC driver allows you to pass JDBC_TRANSACTION_NONE to the setTransactionIsolation
method or specify none as a connection property. However, the getTransactionIsolation
method always reports JDBC_TRANSACTION_READ_UNCOMMITTED when the value is
none. It is your application's responsibility to keep track of what level
you are running if it is a requirement in your application.</p>
<p>In past
releases, the JDBC driver would handle your specifying true for auto-commit
by changing the transaction isolation level to none because the system did
not have a concept of a true auto-commit mode. This was a close approximation
of the functionality, but did not provide the correct results for all scenarios.
This is not done anymore; the database decouples the concept of auto-commit
from the concept of a transaction isolation level. Therefore, it is completely
valid to run at the JDBC_TRANSACTION_SERIALIZABLE level with auto-commit being
enabled. The only scenario that is not valid is to run at the JDBC_TRANSACTION_NONE
level and not be in auto-commit mode. Your application cannot take control
over commit boundaries when the system is not running with a transaction isolation
level.</p>
</div>
<div class="section"><h4 class="sectiontitle">Transaction isolation levels between the JDBC specification
and the iSeries platform</h4><p>The iSeries platform
has common names for its transaction isolation levels that do not match those
names provided by the JDBC specification. The following table matches the
names used by the iSeries platform, but are not equivalent to those
used by the JDBC specification:</p>
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" width="100%" frame="border" border="1" rules="all"><thead align="left"><tr><th align="left" valign="top" id="d0e140">JDBC level*</th>
<th align="left" valign="top" id="d0e142">iSeries level</th>
</tr>
</thead>
<tbody><tr><td valign="top" headers="d0e140 ">JDBC_TRANSACTION_NONE</td>
<td valign="top" headers="d0e142 ">*NONE or *NC</td>
</tr>
<tr><td valign="top" headers="d0e140 ">JDBC_TRANSACTION_READ_UNCOMMITTED</td>
<td valign="top" headers="d0e142 ">*CHG or *UR</td>
</tr>
<tr><td valign="top" headers="d0e140 ">JDBC_TRANSACTION_READ_COMMITTED</td>
<td valign="top" headers="d0e142 ">*CS</td>
</tr>
<tr><td valign="top" headers="d0e140 ">JDBC_TRANSACTION_REPEATABLE_READ</td>
<td valign="top" headers="d0e142 ">*ALL or *RS</td>
</tr>
<tr><td valign="top" headers="d0e140 ">JDBC_TRANSACTION_SERIALIZABLE</td>
<td valign="top" headers="d0e142 ">*RR</td>
</tr>
</tbody>
</table>
</div>
<p>* In this table, the JDBC_TRANSACTION_NONE value is lined up with
the iSeries levels
*NONE and *NC for clarity. This is not a direct specification-to-iSeries level
match.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="transactions.htm" title="A transaction is a logical unit of work. To complete a logical unit of work, several actions may have to be taken against a database.">Transactions</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="transaut.htm" title="By default, JDBC uses an operation mode called auto-commit. This means that every update to the database is immediately made permanent.">Auto-commit mode</a></div>
<div><a href="savepnts.htm" title="Savepoints allow the setting of &#34;staging points&#34; in a transaction. Savepoints are checkpoints that the application can roll back to without throwing away the entire transaction. Savepoints are new in JDBC 3.0, meaning that the application must run on Java Development Kit (JDK) 1.4 or a subsequent release to use them. Moreover, savepoints are new to the Developer Kit for Java, meaning that savepoints are not supported if JDK 1.4 or a subsequent release is not used with previous releases of the Developer Kit for Java.">Savepoints</a></div>
</div>
</div>
</body>
</html>