• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EJB/JDBC Transactions

 
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Could someone clear something up for me

Say I get a JDBC connection from a Datasource (accessed via JNDI) in a Session Bean method that is running inside a Container managed Transaction.

I've read in an earlierpost that the JDBC operations, update etc will be automatically part of the current transaction if you are running under CMT. So rollbacks, commits will apply to these JDBC operations.

Is this correct?


If so where does setAutoCommit(true/false) on the connection come into play in this scenario.

Is the connection acquired with Autocommit false?

What happens if I make it set to true, won't this cause the JDBC operations to be committed irrespective of the Session Transaction status??

Finally in BMT does issuing

UserTransaction ut = context.getUserTransaction();

Mean that acquiring a connection via

InitialContext ic = new InitialContext();
DataSource ds = (DataSource) ic.lookup(dbName);
con = ds.getConnection();

Mean that the JDBC connection is automatically participating in the UserTransaction???

Do you have to issue a begin() on the User Transaction PRIOR to acquring the Connection or doesn't it matter??

Phew my head hurts! Thanks to anyone who helps or can point me in the direction of some succinct article


 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Graham,


Say I get a JDBC connection from a Datasource (accessed via JNDI) in a Session Bean method that is running inside a Container managed Transaction.

I've read in an earlierpost that the JDBC operations, update etc will be automatically part of the current transaction if you are running under CMT. So rollbacks, commits will apply to these JDBC operations.

Is this correct?


Yes it is.


If so where does setAutoCommit(true/false) on the connection come into play in this scenario.

Is the connection acquired with Autocommit false?

What happens if I make it set to true, won't this cause the JDBC operations to be committed irrespective of the Session Transaction status??


Let�s make one thing clear: you can use either JDBC or JTA/JTS api for managing your transactions (for BMT). If you use the JDBC api then the database will manage the transactions and your application must disable the autocomit flag (otherwise it will commit after each sql statement is issued). Transaction boundaries are demarcated by the RDBMS (see the RDBMS documentation for that) and they will end after calling Connection.commit()/rollback() methods. If you use the JTS/JTA api then you use the UserTransaction.begin()/commit()/rollback() methods for demarcating transaction boundaries and this time is the container�s transaction manager that handle the issue. Therefore I believe it won�t matter what your connection setting are.


Finally in BMT does issuing

UserTransaction ut = context.getUserTransaction();

Mean that acquiring a connection via

InitialContext ic = new InitialContext();
DataSource ds = (DataSource) ic.lookup(dbName);
con = ds.getConnection();

Mean that the JDBC connection is automatically participating in the UserTransaction???


Yes you right again


Do you have to issue a begin() on the User Transaction PRIOR to acquring the Connection or doesn't it matter??


Well actually it matters. Once you manually started a transaction, then the container will assume that your bean is using BMT. In this case you must use explicitly the TX_BEAN_MANAGED in your deployment descriptor, which will give your bean the right to use the UserTransaction object. Otherwise the container will throw an exception.


Phew my head hurts! Thanks to anyone who helps or can point me in the direction of some succinct article


I hope your hearth is better now
Regards.
 
Graham VMead
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Valentin,
Thanks very much for the reply, very useful.

I found some blurb in the Sun documentation that says that you cannot use methods such as setAutoCommit(false) commit etc on the connection object when you are using CMT because it would interfere with the containers transaction boundary demarcation.

Namely

"The enterprise bean�s business methods or onMessage method must not use any resource-manager specific transaction management methods that would interfere with the Container�s demarcation of transaction boundaries. For example, the enterprise bean methods must not use the following methods
of the java.sql.Connection interface: commit(), setAutoCommit(...), and rollback() or the following methods of the javax.jms.Session interface: commit() and rollback().
The enterprise bean�s business methods or onMessage method must not attempt to obtain or use the javax.transaction.UserTransaction interface."


Actually I also noticed in the EJB spec it says exactly the same thing about these methods being forbidden when using BMT and that commits etc should always be issued on the UserTransaction object!

Just a couple of more quickies

1) Is it true that gaining access to a JDBC connection via DriverManager.getConnection() rather than via a datasource means that the connection will NOT be participating in the transaction defined via CMT or BMT.

2) Is it against the EJB spec to use JDBC as in 1) within an EJB and handle transaction boundaries yourself rather than using BMT or CMT?

If not what is the benefit of using UserTransaction is it purely for 2 phase commit/distributed transactions??

thanks again Valentin and anyone else who can spare a second to illuminate my confusion

Graham
[ March 10, 2005: Message edited by: Graham VMead ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic