Hi Huisheng,
thanks for your reply.
Integration with Spring is not really an option for us; our DI standard is Guice.
Option 2. doesn't sound optimal either because it introduces an ugly dependency on jBPM; ideally we have dependencies on jBPM services but not on the internals (I think the Command is not really part of the jBPM API?). Apart from that we would end up using different transaction mechanisms for service calls that happen to have a dependency on jBPM (they're wrapped in a Command), and services without jBPM dependency (those don't need to be executed in a Command).
I was hoping for a cleaner solution...
Anyway, as for the other issue: https://community.jboss.org/message/537176
Although I now have got one hibernate SessionFactory shared by my app and jBPM (see ...; not sure if this is a proper fix), things still seem to be running in different transactions. With the standard jbpm.tx.hibernate.cfg.xml (which configures a standard-transaction-interceptor for every command), when I roll back my top-level transaction, the jBPM stuff (executed inside the transaction created by the StandardTransactionInterceptor) is not rolled back.
So what I did was create my own tx.hibernate.cfg.xml, and remove the standard-transaction-interceptors from it. That doesn't really work either (now suddenly calls to "repositoryService.createDeployment().addResourceFromClasspath("myProcess.jpdl.xml").deploy()" seem to not properly insert process definitions in the database; it does insert into JBPM4_DEPLOYMENT, but 3 out of the 4 records from JBPM4_DEPLOYPROP are missing).
Before I dive into the deep, can someone let me know if this is the way to go? What's the way to have jBPM use my own transactions? Should it be possible to remove the standard-transaction-interceptor from the interceptor stack? Or is it strictly forbidden; if so, why?