Yes. I use two databases; one for jBPM and one for the domain data model. There are two different database connections, but they both are part of the same distributed transaction. My stateless session bean takes care of that.
I was hoping not to have to use distributed transactions giving the same underlying database connection is being used.
Well, maybe that is true today. What if tomorrow you no longer use the same underlying database connection?
Perhaps you should make your application not care about it. In my dev environment everything is in the same database, but in my production environment I have two separate databases. My app doesn't care because I use two different datasources.
I was hoping not to have to use distributed transactions giv[en] the same underlying database connection is being used.
Are you sure? The only way two different hibernate sessions use the same jdbc connection at the same time is providing the connection yourself. Otherwise each session will obtain a separate connection (even for the same database) and, in consequence, begin separate local transactions if they are not configured for global transactions.
I should have been more specific. I have implemented a ConnectionProvider that utlilizes ThreadLocal to ensure the same connection is returned.
Let us know how it goes.
Why go to that much trouble?
- Our DBAs do not allow/enable distributed transactions on our databases.
- XA has it's place but recovery can be an issue at times. So, if it is not necessary why add the complexity of multiple resource managers when there is actually only one.
- App servers play the same game by returning the same connection from a "Transactional Resource" (BEA for example) while inside a transaction, so it seemed reasonable.
Aside from using XA, would you have recommended a different approach?