we want to use weblogic’s JTA transaction manager (but managed by Spring), so we declare

jbpm.cfg.xml:

<spring-transaction-interceptor current=”true” />

and in spring context:

<bean id=”workflowTxManager” class=”org.springframework.transaction.jta.WebLogicJtaTransactionManager”>
<property name=”transactionManagerName” value=”javax.transaction.TransactionManager”/>
</bean>

and when i try to deploy the workflow, it tries to run ProcessEngineImpl.checkDb(), which apparently fails with “No existing transaction found for transaction marked with propagation ‘mandatory’”…

@Unsavory: is there a way to _configure_ jBPM to use a custom transaction interceptor? so that instead of spring-managed one i’d overwrite the existing JtaTransactionInterceptor to look for our specific transaction manager and then reference it somehow in jbpm.cfg.xml… that would be the least painful way to do it i guess…

org.springframework.transaction.IllegalTransactionStateException: No existing transaction found for transaction marked with propagation ‘mandatory’
at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:339)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:124)
at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:77)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)

I fixed it by adding the following to my config:

<command-service name=”txRequiredCommandService”>
<retry-interceptor />
<environment-interceptor />
<spring-transaction-interceptor />
</command-service>

Good luck!

IE: Injecting the spring transaction manager into jBPM as I’ve posted above.

It’s right there in the source. Just by looking at the JtaTransaction class you can see why. =)

This is strictly a middleware issue though. As long as you are using spring JTA transactions (J2EE container or 3rd party provided) you will be in the same boat as me.

I really think the crux of the problem is the different transaction requirements between the executor and the core.

That is most likely why your solution (a good one BTW) works in that you can inject the correct transaction boundary (propagation=REQUIRE most likely?) and override the default one for JBPM.

I honestly cannot see how his solution works as I tried that variant and got the same problem I described. He just uses the default executor, but that simply did not work for me.
Maybe because he uses HSQL? Maybe his test workflows are simpler?

Cannot say.

Do note that jBPM4 is not designed to run on a J2EE container! It is designed as a standalone library, which is embeddable in any application, including a J2EE application.

Take for example a look at the demo of Andries Inzé: http://www.inze.be/andries/2009/05/16/demo-on-spring-integration-with-jbpm4/
Here is nowhere a JTA TM used that is bound to JNDI.

The only place where there is a dependency on JNDI is when using the jBPM console built using the demo.setup task.

The problem is with the way the JTA transaction manager is retrieved. jBPM 4 assumes you are running in a J2EE environment such as JBoss and that the transaction manager is bound to a certain jndi name.

In Tomcat/Spring the transaction manager is looked up via Spring’s transaction manager. NOT via JNDI.

The solution I came up with was to modify the jBPM source code’s JtaTransaction class. I make the class @Configurable and inject the spring transaction manager into it.

And then in the 2 methods inside the JtaTransaction class that attempt to retrieve the transaction manager and user transaction from jndi, I use Spring’s transaction manager to do so instead of jndi.

It works, but I wish there was another way.

Yes I did. It always failed when processing timers and other asynchronous jobs. I also tried many variations on it also. (e.g. specifying a separate set of interceptors for the executor)
Basically the closest I came was having processes start up successfully, but the executor fail to start a JTA transaction on jobs.
I even debugged the code and followed the execution. It had the spring interceptor and was entering the transaction code, but of course failed to start a new transaction. I think it was around the concept of REQUIRED vs MANDATORY.
What I wanted was REQUIRED, so it would start one when there was not one but not start a new one otherwise. At one stage I even wrote my own interceptor and injected it manually, but that did not work either.
After about a week I just had to call it and move on.

But I’m sad to hear it doesn’t work for you. Am I right that you are using jBPM4 witg Spring?
Did you take a look at the example project of Andries Inzé? He has a complete application built with the spring integration:

see http://code.google.com/p/jbpm4-spring-demo/

Unfortunately it did not work. Transaction problems up the waazoo no matter what I tried in the config. (and I tried EVERYTHING) So disappointed because I was always so close.

From memory it was a case of the job executor requiring one type of transaction config and the core jbpm system requiring another.

I really think the whole !!MUST HAVE OUR XML FILE OR YOU FAIL!! mentality is letting the project down. The config in general is not that well explained, hard to penetrate and what caused me to waste my time trying to integrate it all.

I could not penetrate the config to manually set the “command-service”(sp?) config for the executor. It just kept getting its config from the core. Also the docs on spring integration are very brief and not nearly enough.
Similar to jbpm3 to be honest. Project = awesome. Config = pain.