Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Surprised by EJB automatic rollback behaviour

 
Robin Meehan
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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()
{
getDAO1().doUpdateA();
getDAO2().doUpdateB();
}
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...
Comments?
 
Phil Sharp
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 http://kb.atlassian.com/content/orion/docs/datasource-configuration/datasource-configuration.html
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:
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic