We have a jBPM workflow that executes custom activities implemented as session EJBs. Upon failure of one of these activities, the enclosing JTA transaction enters into an aborted state. The {{ExecuteJobCmd}} seems to deal with exeptions by executing a {{JobExecutionHandler}} once the current transaction completes. This sequence is assured by the following:
{code:java}transaction.registerSynchronization(jobExceptionHandler);{code}
Unfortunately, since the JTA transaction has already been marked for rollback, this call fails!
The question is, are we looking at a bug that only appears when using JTA transactions ({{org.jbpm.pvm.internal.tx.StandardTransaction}} doesn't care if the transaction is being aborted.) Or are we not scoping our JTA transactions properly?