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?