I've been learning jBPM and working with its Spring integration. This has been a fun experience and pretty strait forward until I ran into the multiple transaction managers issue. It seems known that you can't really share transaction managers with multiple Entity Management Factories in Spring, but the duplicate of everyting (i.e. DataSources, TransactionManagers, and Entity Managment Factories) have been showing a vital limitation.
What I'm observing is an inadvertant closing of transaction manager B when a method wrapped with a transaction manager A proxy delagates to jBPM classes which are configured to use transaction manager B. You get an exception like 'EntityManager is closed, cannot commit transaction'.
What I've tried:
1. Defining a completely different datasource and transaction manager for jBPM's knowledge session than what my other persistence units are using.
2. Using the Bitronix transaction manager for the knowledge session while using spring's JPA manager for my objects.
3. Using a transaction qualifier to wrap top level method with my transaction manager and wrapping jBPM invoker classes with the workflow transaction manager.
4. Not allowing any method that might call a workflow action to be Transactional (this is the only one that works)
It is inconvienent to have my persistence code work, then have a workflow failure and not be able to rollback my last database interaction. I'm wondering if there is anyway to gain this support? I don't really understand the mechanism that is causing the Spring Transactional Apsect proxy to close the jBPM session, so if anyone has any insights into why this is happening that maybe helpful as well.
I've got a complete project I can share demonstrating the issue, it is 40mb with dependecies and 10kb of just source. If you look at the source, the problem transaction is on the 'SynchronousTask' class, comment this out and it will work.