wood burning stoves*
The moose likes JDBC and the fly likes JDBC transactions, JTA transactions, Transaction demarcation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "JDBC transactions, JTA transactions, Transaction demarcation" Watch "JDBC transactions, JTA transactions, Transaction demarcation" New topic

JDBC transactions, JTA transactions, Transaction demarcation

Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
Let's suppose I have this method:

public void doUpdate() throws SQLException
java.sql.Connection conn;
java.sql.Statement stmt;
// ...
// ...
// ...
Since we are using autocommit, the transaction is
committed when we call executeUpdate. Cool.
Here's my question:
What if the caller is using the Java Transaction API?
public void processRequest()
UserTransaction tx;
// ...


The caller is demarcating a transaction.
In this scenario, does JDBC autocommit get ignored?
Does the UserTransaction take precedence over the JDBC transaction?
Sean Sullivan
Ranch Hand

Joined: Sep 09, 2001
Posts: 427
The JDBC 3.0 specification is enlightening.
The JDBC 3.0 specification says:
The default is for auto-commit mode to be enabled when the Connection object is created. If the value of auto-commit is changed in the middle of a transaction, the current transaction is committed. It is an error to enable auto-commit for a connection participating in a distributed transaction, as described in Chapter 12 "Distributed Transactions".
Chapter 12 of the JDBC 3.0 spec discusses Distributed Transactions and JTA:
An XAConnection object is a PooledConnection object that can participate in a distributed transaction. [...]
Participation in a distributed transaction is defined as the work done between invocations of the methods XAResource.start and XAResource.end. Outside these boundaries, the transaction mode is local, and a connection behaves exactly like a local connection. With one exception, there is no difference in how an application participating in a distributed transaction is coded. In contrast to the local case, the boundaries of a distributed transaction must be controlled by an external transaction manager that is coordinating the work of multiple connections. For this reason, it is an error for applications to call any of the following Connection methods while they are participating in a distributed transaction:
- setAutoCommit(true)
- commit
- rollback
- setSavepoint
The JDBC driver throws an SQLException if one of these operations is attempted on a connection that is participating in a distributed transaction. If the connection is later used for a local transaction, these operations are legal at that point.
Applications should also refrain from calling Connection.setTransactionIsolation within the bounds of a distributed transaction. The resulting behavior is implementation-defined.
If a connection has auto-commit mode already enabled at the time it joins a global transaction, the attribute will be ignored. The auto-commit behavior will resume when the connection returns to local transaction mode.
It is sorta covered in the JavaRanch Style Guide.
subject: JDBC transactions, JTA transactions, Transaction demarcation
Similar Threads
JTA, java.sql.Connection.close()
what is JTA in hibernate?
using JTA without using EJB
How to rollback in components those have their own transaction?
Retrieve CMT transaction in code