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

Where should we hide our transaction begin & commit calls?

 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to decide where I should code a transaction (txn).begin and transaction (txn).commit method.

I've seen them put in DAO objects, using the DAO pattern, but DAO objects should be independent of the underlying database, database connection mechanism, and txn mechanism. So, why ask a developer using Hibernate to put a txn.begin method in there that uses Hibernate, when at deployment time, you may use JTA? So, I don't like it in the DAO. Maybe I'm wrong?

Right now I've got it in a HibernateUtil class, but that just looks silly. I've got a real elegant DAO that abstracts out everything, and right above and below calls to he DAO, I've got this class called HibernateUtil that obviously is tightly tied to the hibernate implementation.

Should the tranaction mechanism be looked up through a ServiceLocator pattern? Thus allowing the implementation of the txn mechanism to be switched in and out easily? So, I'd grab the txn through the ServiceLocator, and then, begin the txn, and then invoke the DAOs, which are implemented by Hibernate under the covers?

Overall, I've got a very elegant design, but my the lack of abstraction on the txn part is far from elegant.

-Cameron McKenzie
 
Arun Kumarr
Ranch Hand
Posts: 661
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
have you thought about using transactions declaratively.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic