• 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
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Transaction ManageMent in Spring with Hibernate

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Following are some of relavent code snippets from my project...What i want ot ask is that whether one must use HibernateTransactionManager if he is using Hibernate in DAO classes to fire queries. Because we are accidentally using DatasourceTransactionManager with Hibernate Query Language in DAO implementation classes. Please calrify my doubts .According to me it shouldn't matter which transaction management strategy we are using...wat say??

My applicationcontext.xml



My BasetransactionAction which get a Particular transactionManager Instance and starts the transaction


My BaseAction class which provides various methods to get differenct types of transaction templates and hence different types of transaction managers:



one of my action classes which gives call to UserServiceserviceImpl class


My UserServiceImpl class whioch ultimately gives call to UserDAOImpl
(friend);

} catch (Exception e) {
throw new BusinessException(e);
}

return null;
}
}
[/code]
Finally My UserDAO implementation for the above service method
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I understand correctly your design, we have the following flow:

1. User login submit

2.
is called, which is in fact

because it's not overriden neither in AddFriendAction nor in BaseTransactionAction

3. Call is delegated to

which invoke the BaseTransactionAction version of this method (not overriden in AddFriendAction and abstract in BaseAction)

4. In this method you create an ActionTransactionCallback instance:


5. This callback is then used with the code:


Here, the doInTransaction method of the callback will be invoked, within a transaction exposed by the transaction manager referenced by the given transaction template.
getHibernateTransactionTemplate() returns the Spring bean with id BEAN_HIBERNATE_TRANSACTION_TEMPLATE="transactionManager" which is defined of class org.springframework.orm.hibernate3.HibernateTransactionManager in your Spring application context. This transaction manager manages transactions for its session factory, build on your datasource "neebalDataSource".

Back to the doInTransaction method, the call to

triggers the one from AddFriendAction, calling your UserServiceImpl and the underlying UserDaoImpl.

=> In this scenario, transactions are in fact managed by the HibernateTransactionManager. Well, I might have miss something , but I can't see here where you

are accidentally using DatasourceTransactionManager with Hibernate Query Language in DAO implementation classes

.

Your Spring application context also declares also a bean named "txManager", of class org.springframework.jdbc.datasource.DataSourceTransactionManager. This one will manage transactions around the JDBC connections opened from your datasource "neebalDataSource". This will be the case if you use Spring JdbcTemplate for example, but not for HibernateTemplate which is automatically managed by the HibernateTransactionManager if present.

To sum up, I would use the following:

Hibernate-only transaction => HibernateTransactionManager
JDBC-only transaction => DataSourceTransactionManager
Mixed Hibernate-JDBC transaction (same datasource) => HibernateTransactionManager
Mixed transactional datasources => JtaTransactionManager

By the way, try to keep data access in your Dao layer, business in your service layer (with transaction management), and presentation in your presentation layer: a Struts action should not know anything about Hibernate or JDBC or whatever; a service can be transactional, but it should be transparent for the caller (your Struts action)... The more a functionality is confined, the easier it is to debug/enhance/implement differently without breaking the whole application.

Hope this helps
 
s vai
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hey Chris

thanks a lot for your input...

actually i made a mistake while posting the post... sorry for that ...but when i replace "getHibernateTransactionTemplate()" with "getTransactionTemplate()" which actually uses datasourcetransactionManager the code and flow works just fine....why??? if i use HibernateTemplate in DAO layer you say i "must" (correct me if i am wrong) use HibernateTransactionTemplate...if yes then i am violating this by using DatasourceTransactionManager.......and still all is well...

where exactly my code would break if i use DatasourceTrnsactionManager instead of HibernateTransactinManager

Please disillusion me from this confusion
 
Christian Gossart
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well transactions are a tricky topic

org.springframework.orm.hibernate3.LocalSessionFactoryBean exposes by default a "transaction-aware" SessionFactory.

Here I assume you extends org.springframework.orm.hibernate3.support.HibernateDaoSupport with your AbstractHibernateDAO, to get access to Spring HibernateTemplate. In that case, when your UserDaoImpl invoke , the current Hibernate Session will participate to any Spring-managed transaction, no matter this transaction management strategy or synchronization mechanism (cf. the LocalSessionFactoryBean javadoc). In your case, even if the transaction comes from a DataSourceTransactionManager, the Hibernate Session used by your DAO is aware of it: transaction is opened, JDBC statement created by the HibernateTemplate in the Session is flushed to the database, connection is closed, Session is closed, and the transaction completes.

That's my own understanding, and I'd be glad to see someone confirm or infirm this

 
s vai
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hey Chris,

thanks a lot...at least i got someone to support what i was thinking abt....lets hope somebody puts more light on it.....

 
reply
    Bookmark Topic Watch Topic
  • New Topic