Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

JDBC transactions, JTA transactions, Transaction demarcation

 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's suppose I have this method:

public void doUpdate() throws SQLException
{
java.sql.Connection conn;
java.sql.Statement stmt;
// ...
conn.setAutoCommit(true);
// ...
stmt.executeUpdate(strSQLUpdate);
// ...
}
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?
Suppose:
public void processRequest()
{
UserTransaction tx;
// ...
tx.begin();
doUpdate();
tx.commit();

}

The caller is demarcating a transaction.
In this scenario, does JDBC autocommit get ignored?
Does the UserTransaction take precedence over the JDBC transaction?
http://java.sun.com/products/jta/
http://java.sun.com/products/jdbc/
 
Sean Sullivan
Ranch Hand
Posts: 427
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
}}
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic