• 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

UNCLEAR - Does transaction propogate to JDBC DAO?

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

I find myself working through another departments code. I find a session bean which has a method foo() that participates in a transaction. This method then instantiates a JDBC Data Access Object and calls a method bar(). This method obtains its own connection from the same JNDI DataSource and performs and insert/update and closes its own connection (connection creation and closure occurs within bar, there is no explicit transaction handling code in bar()).

My question, if the larger transaction in foo() gets rolled back for some reason, will the activity in bar() get rolled back also? I have not come across any documentation that indicates either way. I would like to be 100% sure. If you find a resource, please let me know.

I have read through the head first book and it does not mention what happens when and EJB method calls a non EJB class that does JDBC work. Could someone please clarify this for me?

Best Regards,

Joshua
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This should work predicatably as you expect. It even works in case where the bar() method is implemented in a 'different' EJB. Also, if the bar() method should update a table in a different database (from different vendor too!), it can achieve consistent rollback by way of distributed transaction (remember two-phase commit?). The EJB container guarantees local as well as distributed transaction.

Though the spec explicitly does not discuss these scenarios, it does mention about local and distributed transaction, which is same as the case above.
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So you are saying that even though this DAO (which is not a bean and manages its own connection) will still participate in the same transaction as foo()?

I definitely want to believe this is true, but I need to be sure. If you happen to come across any documentation, please post it here.

Thanks,

Joshua
 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This question is not related to SCBCD, so, it is better to post similar questions at:
https://coderanch.com/forums/f-11/EJB-JEE

Nick
 
Keerthi P
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So you are saying that even though this DAO (which is not a bean and manages its own connection) will still participate in the same transaction as foo()?



Yes. absolutely, provided all the participating components (EJB, DAO) are running under a J2EE container.

If the DAO is on a remote machine and if EJB makes a plain Java RMI invocation on it, it fails miserably. The transaction simply won't propagate. You need RMI-IIOP to carry transaction and security information across containers.

If you happen to come across any documentation, please post it here.


You best bet will be trying it yourself.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic