propagation of EJB transaction into Spring/Hibernate

[wciesiel]

Hi there,

I've got SLSB session facade using Spring/Hibernate POJOs as persistance layer. On the service methods I can set EJB transaction type. Is this propagated somehow onto operations further into service?

ie: I have MyService.doSomeOps() method calling:
{ getFirstDao.doSomething();
getSecondDao.doSomething();
getThirdDao.doSomething();
}
If I set ejb trasaction as REQUIRED for doSomeOps() - will this work as it should ie. rollbacking transaction on error in any of those 3 inner operations? Can I set Spring/Hibnernate DataAccessException annotational handlers (rollbackFor etc) within doSomeOps() ?

[Andreas Senft]

Information about spring's transaction management can be found here

Hope this helps,
Andreas

[Juergen Hoeller]

As long as you are using Spring's JtaTransactionManager, you should see proper participation in EJB-driven transactions. JtaTransactionManager will automatically detect an existing JTA transaction and participate in it.

Alternatively, consider not specifying any Spring transaction management at all, i.e. purely relying on EJB CMT. Spring DAOs will usually automatically participate in existing JTA transactions, for example when based on JdbcTemplate or HibernateTemplate. If all your Spring transaction attributes say "PROPAGATION_REQUIRED" and will execute within existing EJB CMT transactions in all cases, they're effectively redundant.

Juergen

[EdwinDhondt]

Juergen,

So if I use CMT SLSBs, that is EJB-driven JTA transactions, then I don't have to specify a TransactionManager (e.g. JTATransactionManager) in my Spring configuration files, and still Spring will ensure everything executes in the ejb/container-provided transaction ?
Is that correct ?
Could you provide us a small example configuration file that shows this scenario ? E.g. CMT SLSB using Spring and Hibernate DAOs ?

Kind regards,
EDH

[kkus]

In CMT, app server is supposed to use a javax.transaction.TransactionManager instance to manage transaction. Mostly it is a JtaTransactionManager. What Spring does is go find such a transaction manger through JNDI. So it is critical to specify your data source as a type of XA data source instead of local one in your data source bean configuration. Once finding such a data source(it is called WrappedDataSource in JBoss), it will get transaction manger, connection manger etc. Based on transaction's status Spring can determine if it is an active transaction or not. Then it will reuse existing CMT transaction or create a new one.

In my case JBoss 3.2.8SP1+Spring 1.2.6+Hibernate 3.05 I have to specify transaction attribute PROPAGATION_SUPPORTS in HibernateTransactionManager. Otherwise I will get a rollback error saying "can't commit under a managed transaction" if transaction attribute is set as PROPAGATION_REQUIRED. Hope it helps.

[seldrick]

So if I use CMT SLSBs, that is EJB-driven JTA transactions, then I don't have to specify a TransactionManager (e.g. JTATransactionManager) in my Spring configuration files, and still Spring will ensure everything executes in the ejb/container-provided transaction ?
Is that correct ?
Could you provide us a small example configuration file that shows this scenario ? E.g. CMT SLSB using Spring and Hibernate DAOs ?

+1 : I'm really interested in the response to that question !

What are the conditions to make working some CMT SLSB (for declarative transaction) using Spring JdbcTemplate (without any declarative transaction defined in Spring) ?
Is it ok if the datasource used in JdbcTemplate is a JNDI Datasource ?

Regards,

Joe

[dejanp]

If we are talking about pure jdbc the answer is simple: you have to use jndi datasource and you need no transaction handling on the Spring level at all. (the datasource itself is JTA-aware, when you get a connection it's going to be transaction bound, if there is an active JTA transaction)

With Hibernate on the other hand the story is not as simple - Hibernate needs to know it's running inside a transaction that's externally handled as it needs to flush unexecuted sql before commit. You will (at least) need to set jtaTransactionManager property of the LocalSessionFactoryBean.

[seldrick]

If we are talking about pure jdbc the answer is simple: you have to use jndi datasource and you need no transaction handling on the Spring level at all. (the datasource itself is JTA-aware, when you get a connection it's going to be transaction bound, if there is an active JTA transaction)

ok ! the magic happens in JNDI Datasource since it is JTA-aware (that the point I didn't knew) and I don't need to do anything in Spring to propagate the transactions initiated by SLSB (only define a JNDI Datasource for JdbcTemplate).

The architecture of my app is classic :
SLSB layer for remoting and tx --> Service layer --> DAO layer

Now if I want to test outside container my service layer, I only have to add declarative spring transaction in service interface and use a commons-dbcp BasicDataSource instead of JNDI Datasource, right ?
(I would like to use only spring transaction but my company requires using SLSB declarative transactions in production environnement)

Many thanks dejanp for the clear explanation, I have a better understanding on how transactions work with SLSB and JNDI datasource !

Regards,

Joel

[dejanp]

For tests outside of the container I'd add a separate spring context that would be used only in test environment and where you can define a test transaction manager, datasource and transaction interceptors you need. That way you'll have a clean production environment with no overhead in configuration or runtime at all.

[seldrick]

That's exactly what I had in mind !

Thanks again for your light.

Joel