[jboss-dev-forums] [Design of JCA on JBoss] - Re: Allow setAutoCommit(false) on managed connections

adrian@jboss.org do-not-reply at jboss.com
Tue Jul 24 12:18:10 EDT 2007


"bill.burke at jboss.com" wrote : I don't think you are listening to me.  connection.commit() /rollback()SHOULD fail as it is a state change.  setAutoCommit(false) should succeed as there is no state change to the connection if auto commit is already false.
  | 
  | Thirdparty code may not be doing commit(), rollback(), but may only be doing setAutoCommit(false).  Which should be perfectly fine, again, because there is no state change to the connection.  This could be what the user is running into.  I don't know.
  | 

Impossible. The code would never work without a commit() outside a JTA transaction.
connection.close() does a rollback if there was no commit.

anonymous wrote : 
  | Weston/myself had similar spec religiousness debates with Mark Little around allowing multiple non-XA resources in a transaction.
  | 
  | Morale of the story?  You may know something is wrong and not the right way to do it, but there may be no other way because you don't control all the variables.
  | 

But using non-XA resources works in most cases (there are some failures
that don't). 

What's important is that it doesn't break code using XA resources to support it.

There's absolutely no way

  | Connection c = datasource.getConnection();
  | try
  | {
  |    c.setAutoCommit(false)
  |    // do stuff but don't commit
  | }
  | finally
  | {
  |    c.close();
  | }
  | 

works in any environment. It's just broken code.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4067098#4067098

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4067098



More information about the jboss-dev-forums mailing list