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
