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

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 &#34;native&#34; 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>