228 lines
16 KiB
HTML
228 lines
16 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="Distributed transactions" />
|
||
|
|
<meta name="abstract" content="Typically, transactions in Java Database Connectivity (JDBC) are local. This means that a single connection performs all the work of the transaction and that the connection can only work on one transaction at a time. When all the work for that transaction has been completed or has failed, commit or rollback is called to make the work permanent, and a new transaction can begin. There is, however, also advanced support for transactions available in Java that provides functionality beyond local transactions. This support is fully specified by the Java Transaction API." />
|
||
|
|
<meta name="description" content="Typically, transactions in Java Database Connectivity (JDBC) are local. This means that a single connection performs all the work of the transaction and that the connection can only work on one transaction at a time. When all the work for that transaction has been completed or has failed, commit or rollback is called to make the work permanent, and a new transaction can begin. There is, however, also advanced support for transactions available in Java that provides functionality beyond local transactions. This support is fully specified by the Java Transaction API." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jdbc.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jtacommit.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jtamulticonn.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jtamultitx.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jtatxeffect.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jtatxend.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jtatxsuspend.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="distrans" />
|
||
|
|
<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>Distributed transactions</title>
|
||
|
|
</head>
|
||
|
|
<body id="distrans"><a name="distrans"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Distributed transactions</h1>
|
||
|
|
<div><p>Typically, transactions in Java™ Database Connectivity (JDBC) are local.
|
||
|
|
This means that a single connection performs all the work of the transaction
|
||
|
|
and that the connection can only work on one transaction at a time. When all
|
||
|
|
the work for that transaction has been completed or has failed, commit or
|
||
|
|
rollback is called to make the work permanent, and a new transaction can begin.
|
||
|
|
There is, however, also advanced support for transactions available in Java that
|
||
|
|
provides functionality beyond local transactions. This support is fully specified
|
||
|
|
by the Java Transaction API.</p>
|
||
|
|
<p>The Java Transaction API (JTA) has support for complex transactions.
|
||
|
|
It also provides support for decoupling transactions from Connection objects.
|
||
|
|
As JDBC is modeled after the Object Database Connectivity (ODBC) and the X/Open
|
||
|
|
Call Level Interface (CLI) specifications, JTA is modeled after the X/Open
|
||
|
|
Extended Architecture (XA) specification. JTA and JDBC work together to decouple
|
||
|
|
transactions from Connection objects. By decoupling transactions from Connection
|
||
|
|
objects, this allows you to have a single connection work on multiple transactions
|
||
|
|
concurrently. Conversely, it allows you to have multiple Connections work
|
||
|
|
on a single transaction.</p>
|
||
|
|
<p><a href="http://java.sun.com/products/jta/" target="_blank">Java Transaction
|
||
|
|
API (JTA) 1.0.1 specification</a></p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> If you are planning to work with JTA, refer to <a href="jdbcgets.htm">Get
|
||
|
|
started with JDBC</a> for more information about required Java Archive
|
||
|
|
(JAR) files in your extensions classpath. You want both the JDBC 2.0 optional
|
||
|
|
package and the JTA JAR files (these files are found automatically by the
|
||
|
|
JDK if you are running JDK 1.4 or a subsequent version). These are not found
|
||
|
|
by default.</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Transactions with JTA</h4><p>When JTA and JDBC are used
|
||
|
|
together, there are a series of steps between them to accomplish transactional
|
||
|
|
work. Support for XA is provided through the XADataSource class. This class
|
||
|
|
contains support for setting up connection pooling exactly the same way as
|
||
|
|
its ConnectionPoolDataSource superclass.</p>
|
||
|
|
<p>With an XADataSource instance,
|
||
|
|
you can retrieve an XAConnection object. The XAConnection object serves as
|
||
|
|
a container for both the JDBC Connection object and an XAResource object.
|
||
|
|
The XAResource object is designed to handle XA transactional support. XAResource
|
||
|
|
handles transactions through objects called transaction IDs (XIDs).</p>
|
||
|
|
<p>The
|
||
|
|
XID is an interface that you must implement. It represents a Java mapping
|
||
|
|
of the XID structure of the X/Open transaction identifier. This object contains
|
||
|
|
three parts:</p>
|
||
|
|
<ul><li>A global transaction's format ID</li>
|
||
|
|
<li>A global transaction ID</li>
|
||
|
|
<li>A branch qualifier</li>
|
||
|
|
</ul>
|
||
|
|
<p>See the JTA specification for complete details on this interface.</p>
|
||
|
|
<p><a href="jtacommit.htm">Example: Use JTA to handle a transaction</a> shows
|
||
|
|
how to use JTA to handle a transaction in an application.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use UDBXADataSource support for pooling and distributed transactions</h4><p>The Java Transaction
|
||
|
|
API support provides direct support for connection pooling. UDBXADataSource
|
||
|
|
is an extension of a ConnectionPoolDataSource, allowing application access
|
||
|
|
to pooled XAConnection objects. Since UDBXADataSource is a ConnectionPoolDataSource,
|
||
|
|
the configuration and use of the UDBXADataSource is the same as that described
|
||
|
|
in <a href="poolwdts.htm">Use DataSource support for object pooling</a>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">XADataSource properties</h4><p>In addition to the <a href="poolprop.htm">properties</a> provided by the ConnectionPoolDataSource,
|
||
|
|
the XADataSource interface provides the following properties:</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="d0e90">Set method (data type)</th>
|
||
|
|
<th align="left" valign="top" id="d0e92">Values</th>
|
||
|
|
<th align="left" valign="top" id="d0e94">Description</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td valign="top" headers="d0e90 ">setLockTimeout (int)</td>
|
||
|
|
<td valign="top" headers="d0e92 ">0 or any positive value</td>
|
||
|
|
<td valign="top" headers="d0e94 ">Any positive value is a valid lock timeout (in seconds) at the transaction
|
||
|
|
level. <p>A lock timeout of 0 means that there is no lock timeout value enforced
|
||
|
|
at the transaction level, although there may be one enforced at other levels
|
||
|
|
(the job or the table).</p>
|
||
|
|
<p>The default value is 0.</p>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e90 ">setTransactionTimeout (int)</td>
|
||
|
|
<td valign="top" headers="d0e92 ">0 or any positive value</td>
|
||
|
|
<td valign="top" headers="d0e94 ">Any positive value is a valid transaction timeout (in seconds). <p>A
|
||
|
|
transaction timeout of 0 means that there is no transaction timeout value
|
||
|
|
enforced. If the transaction is active for longer than the timeout value,
|
||
|
|
it is marked rollback only, and subsequent attempts to perform work under
|
||
|
|
it causes an exception to occur.</p>
|
||
|
|
<p>The default value is 0.</p>
|
||
|
|
</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">ResultSets and transactions</h4><p>Besides demarcating
|
||
|
|
the start and end of a transaction as shown in the previous example, transactions
|
||
|
|
can be suspended for a time and resumed later. This provides a number of scenarios
|
||
|
|
for ResultSet resources that are created during a transaction.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Simple transaction end</h4><p>When you end a transaction,
|
||
|
|
all open ResultSets that were created under that transaction automatically
|
||
|
|
close. It is recommended that you explicitly close your ResultSets when you
|
||
|
|
are finished using them to ensure maximum parallel processing. However, an
|
||
|
|
exception results if any ResultSets that were opened during a transaction
|
||
|
|
are accessed after the XAResource.end call is made.</p>
|
||
|
|
<p>See <a href="jtatxend.htm">Example:
|
||
|
|
End a transaction</a> that shows this behavior.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Suspend and resume</h4><p>While a transaction is suspended,
|
||
|
|
access to a ResultSet created while the transaction was active is not allowed
|
||
|
|
and results in an exception. However, once the transaction is resumed, the
|
||
|
|
ResultSet is available again and remains in the same state it was in before
|
||
|
|
the transaction was suspended.</p>
|
||
|
|
<p>See <a href="jtatxsuspend.htm">Example:
|
||
|
|
Suspend and resume a transaction</a> that shows this behavior.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Effecting suspended ResultSets</h4><p>While a transaction
|
||
|
|
is suspended, the ResultSet cannot be accessed. However, Statement objects
|
||
|
|
can be reprocessed under another transaction to perform work. Because JDBC
|
||
|
|
Statement objects can have only one ResultSet at a time (excluding the JDBC
|
||
|
|
3.0 support for multiple concurrent ResultSets from a stored procedure call),
|
||
|
|
the ResultSet for the suspended transaction must be closed to fulfill the
|
||
|
|
request of the new transaction. This is exactly what happens.</p>
|
||
|
|
<p>See <a href="jtatxeffect.htm">Example: Suspended ResultSets</a> that shows this
|
||
|
|
behavior.</p>
|
||
|
|
<p><strong>Note:</strong> Although JDBC 3.0 allows a Statement to have
|
||
|
|
multiple ResultSets open simultaneously for a stored procedure call, they
|
||
|
|
are treated as a single unit and all of them close if the Statement is reprocessed
|
||
|
|
under a new transaction. It is not possible to have ResultSets
|
||
|
|
from two transactions active simultaneously for a single statement.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Multiplexing</h4><p>The JTA API is designed to decouple
|
||
|
|
transactions from JDBC connections. This API allows you to have either multiple
|
||
|
|
connections work on a single transaction or a single connection work on multiple
|
||
|
|
transactions concurrently. This is called <strong>multiplexing</strong> and many complex
|
||
|
|
tasks can be performed that cannot be accomplished with JDBC alone.</p>
|
||
|
|
<p>This <a href="jtamulticonn.htm">example</a> shows multiple connections working
|
||
|
|
on a single transaction.</p>
|
||
|
|
<p>This <a href="jtamultitx.htm">example</a> shows
|
||
|
|
a single connection with multiple transactions taking place at once.</p>
|
||
|
|
<p>For
|
||
|
|
further information on using JTA, see the JTA specification. The JDBC 3.0
|
||
|
|
specification also contains information on how these two technologies work
|
||
|
|
together to support distributed transactions.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Two-phase commit and transaction logging</h4><p>The JTA
|
||
|
|
APIs externalize the responsibilities of the distributed two-phase commit
|
||
|
|
protocol completely to the application. As the examples have shown, when using
|
||
|
|
JTA and JDBC to access a database under a JTA transaction, the application
|
||
|
|
uses the XAResource.prepare() and XAResource.commit() methods or just the
|
||
|
|
XAResource.commit() method to commit the changes.</p>
|
||
|
|
<p>In addition, when
|
||
|
|
accessing multiple distinct databases using a single transaction, it is the
|
||
|
|
application's responsibility to ensure that the two-phase commit protocol
|
||
|
|
and any associated logging required for transaction atomicity across those
|
||
|
|
databases are performed. Typically, the two-phase commit processing across
|
||
|
|
multiple databases (that is, XAResources) and its logging are performed under
|
||
|
|
the control of an application server or transaction monitor so that the application
|
||
|
|
itself does not actually concern itself with these issues.</p>
|
||
|
|
<p>For example,
|
||
|
|
the application may call some commit() method or return from its processing
|
||
|
|
with no errors. The underlying application server or transaction monitor would
|
||
|
|
then begin processing for each database (XAResource) that participated in
|
||
|
|
the single distributed transaction.</p>
|
||
|
|
<p>The application server would use
|
||
|
|
extensive logging during the two-phase commit processing. It would call the
|
||
|
|
XAResource.prepare() method in turn for each participant database (XAResource),
|
||
|
|
followed by a call to the XAResource.commit() method for each participant
|
||
|
|
database (XAResource).</p>
|
||
|
|
<p>If a failure occurs during this processing, the
|
||
|
|
application server's transaction monitor logs allow the application server
|
||
|
|
itself to subsequently use the JTA APIs to recover the distributed transaction.
|
||
|
|
This recovery, under the control of the application server or transaction
|
||
|
|
monitor, allows the application server to get the transaction to a known state
|
||
|
|
at each participant database (XAResource). This ensures a well-known state
|
||
|
|
of the entire distributed transaction across all participant databases.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<ul class="ullinks">
|
||
|
|
<li class="ulchildlink"><strong><a href="jtacommit.htm">Example: Use JTA to handle a transaction</a></strong><br />
|
||
|
|
This is an example of how to use the Java Transaction API (JTA) to handle a transaction
|
||
|
|
in an application.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="jtamulticonn.htm">Example: Multiple connections that work on a transaction</a></strong><br />
|
||
|
|
This is an example of how to use multiple connections working on a single transaction.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="jtamultitx.htm">Example: Use a connection with multiple transactions</a></strong><br />
|
||
|
|
This is an example of how to use a single connection with multiple transactions.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="jtatxeffect.htm">Example: Suspended ResultSets</a></strong><br />
|
||
|
|
This is an example of the how a Statement object is reprocessed under another transaction to perform work.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="jtatxend.htm">Example: End a transaction</a></strong><br />
|
||
|
|
This is an example of ending a transaction in your application.</li>
|
||
|
|
<li class="ulchildlink"><strong><a href="jtatxsuspend.htm">Example: Suspend and resume a transaction</a></strong><br />
|
||
|
|
This is an example of a transaction that is suspended and then is resumed.</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="jdbc.htm" title="The IBM Developer Kit for Java JDBC driver, also known as the "native" driver, provides programmatic access to iSeries database files. Using the Java Database Connectivity (JDBC) API, applications written in the Java language can access JDBC database functions with embedded Structured Query Language (SQL), run SQL statements, retrieve results, and propagate changes back to the database. The JDBC API can also be used to interact with multiple data sources in a distributed, heterogeneous environment.">Access your iSeries database with the IBM Developer Kit for Java JDBC driver</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|