Win a copy of Java Mock Exams (software) this week in the Programmer Certification (OCPJP) forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Is the CMT of a SS EJB passed on to the DAO?

Jeevan Sunkersett
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I wish to use CMT (declerative transaction) in stateless EJB which would invoke DAO (simple java classes) who use JDBC for database i/o.
<<I do not want to/ cannot use entity beans; client reasons>>

Would the transaction started by container in EJB propogated to DAO?
Who fires the explicit commit or rollback? EJB or DAO?

I could only think off:
1) The DAO developer must set autoCommit to FALSE and *never* do a commit or rollback on the connection in jdbc (DAO).

2) instead DAO throws a SQLException which will be handled in the ss EJB which will do an explicit sessionContext.setRollbackOnly() in a catch block; maintaining DB consistency

But then the following issues crop up:
1. Would a explicit commit() be required? will the EJB have to do it or the container will?
2. a strict check on the DAO developer would have to kept - must set AutoCommit FALSE, must never do an explicit commit or rollback, and do not know what more.

Any comments?

Mark Carmack
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You do not need to invoke Connection.commit or Connection.rollback if a transaction is controlled by JTA. In fact, every decent application server should throw an exception if you attempt to do so. A call to setAutoCommit on a managed connection is illegal as well.

The CMT will automatically commit/rollback changes made by your DAOs, as long as you use a JTA-aware data source (i.e one configured in the application server and obtained from JTA). Make sure you do *not* retrieve JDBC connections directly from a driver manager or a third-party connection pool that is not part of the app server.

Benoît de Chateauvieux
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeevan,

The JTA transaction of a CMT SB is attached to the thread.
You can invoke a simple class in the same transactional context (but your class wont be able to interact with your transaction in a simple way).

Your DAO can throw an exception.
If your EJB doesn't catch it, the container will:
- log the exception.
- rollback the transaction.
- discard the bean instance.
Your EJB can catch it and do a setRollbackOnly on the transaction.

Without exception or setRollbackOnly, the container will commit the transaction automatically when the method of your EJB returns.
If you try to do a commit or a rollback on a Container Managed Transaction, you'll get an exception.

I understand that you don't want to use EntityBeans but if you have access to Java 1.5 in your application, why don't you implement your DAO as a Stateless SessionBean and use JPA for your database interactions ?
That way, you can control your transaction in every layers and even include the database commit/rollback in the same transactional context.

What are you doing? You are supposed to be reading this tiny ad!
the new thread boost feature brings a LOT of attention to your favorite threads
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!