172 lines
10 KiB
HTML
172 lines
10 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="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 "staging points" 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>
|