File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes EJB and other Java EE Technologies and the fly likes Surprised by EJB automatic rollback behaviour Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Surprised by EJB automatic rollback behaviour" Watch "Surprised by EJB automatic rollback behaviour" New topic

Surprised by EJB automatic rollback behaviour

Robin Meehan

Joined: Jan 12, 2002
Posts: 2
I'm using Orion, but it doesn't really matter for my post. I have a BMP entity bean that uses two data access objects (DAOs) to do some database access as follows:
void ejbBusinessMethod()
Each DAO is responsible for getting its own connection from the container's db pool. When the second DAO call fails, the update from the first one is committed (rather than rolled back by the container), even though I have a 'required' transaction attribute for the bean's methods. I presume this is because each DAO gets its own connection from the pool, and so the EJB container rolls back/commits each one separately, rather than as one in the transaction.
I guess the fix is to pass a Connection object into each DAO so they can share it - haven't had time to try it yet...
Phil Sharp
Ranch Hand

Joined: Nov 08, 2001
Posts: 40
I think your analysis is probably correct however I do not think it has to be that way.
Part of EJBs\application servers power is that they can handle distributed transactions - ie transactions that involve more than one database and so necessarily more than connection would be required in the transaction to facitalitate this. One thing to note is that you would need to use an XA driver.
I have never tried doing this so would be interested to find out if it works.
Have to say your solution of passing the connection is probably the way to go.
Finally some questions of my own which I would appreciate any knowledgeable person answering. Are multiple transactions happening here? My analysis is that if each DAO is creating a new connection (I know it is not really but from the point of view of the application it is I think) then the transaction can only have a lifetime while the connection is instantiated therefore two transactions must be occuring with the first one by default being committed. This is presumably separate from a transaction controlled by the application server?
More questions than answers I think, oh well hopefully somebody else can be more helpful.
Robin Meehan

Joined: Jan 12, 2002
Posts: 2
I've sorted it out now. I did re-code it so I could pass Connection objects into each of my DAOs, and it made no difference! Then I thought it was related to my Orion datasource or ejb-jar.xml setup, and it was. I got the solution from the excellent resource
Basically, the datasource I was using did not support container-managed transactions, as I was looking for the wrong JNDI name in my code when getting a datasource.
Works a lot better now!
Interestingly, even if I use a different Connection for multiple DAO calls in a single EJB method call, the Orion container rolls them all back correctly or commits them correctly. The joys of EJBs... :roll:
I agree. Here's the link:
subject: Surprised by EJB automatic rollback behaviour
It's not a secret anymore!