Possible JTA Rollback Bug(s)


I have two problems I’m trying to figure out.

I’m trying to configure a process engine with JTA. I’m using the JtaProcessEngineConfiguration (we are not using spring) and at least on the surface looked like it is working. However, when I execute my code to deploy a process I notice that it is still immediately visible in other transactions. This is the first problem, because I don’t feel like I should be able to see that until the global transaction commits. I think this is a bug, but I’m not sure as I’m not a JTA expert.

Next issue is that I’m artificially testing it by throwing a RuntimeException after deployment. I see that it is trying to do an UnregisterDeploymentCmd, but it gets a NullPointerException in AbstractManager on this line:
so even unregistering the deployment doesn’t work. This definitely seems like a bug to me, I’ve stepped through and Context.getCommandContext() is returning null.
java.lang.NullPointerException at org.camunda.bpm.engine.impl.persistence.AbstractManager.getCurrentAuthentication(AbstractManager.java:256) at org.camunda.bpm.engine.impl.persistence.entity.AuthorizationManager.checkCamundaAdmin(AuthorizationManager.java:463) at org.camunda.bpm.engine.impl.cmd.UnregisterDeploymentCmd.execute(UnregisterDeploymentCmd.java:39) at org.camunda.bpm.engine.impl.persistence.deploy.DeploymentFailListener.execute(DeploymentFailListener.java:35) at org.camunda.bpm.engine.impl.cfg.jta.JtaTransactionContext$TransactionStateSynchronization.afterCompletion(JtaTransactionContext.java:102) at com.atomikos.icatch.jta.Sync2Sync.afterCompletion(Sync2Sync.java:61) at com.atomikos.icatch.imp.CoordinatorImp.notifySynchronizationsAfterCompletion(CoordinatorImp.java:441) at com.atomikos.icatch.imp.CoordinatorStateHandler.rollbackWithAfterCompletionNotification(CoordinatorStateHandler.java:564) at com.atomikos.icatch.imp.ActiveStateHandler.rollback(ActiveStateHandler.java:279) at com.atomikos.icatch.imp.CoordinatorImp.rollback(CoordinatorImp.java:577) - locked <0x6c0a> (a com.atomikos.finitestates.FSMImp) at com.atomikos.icatch.imp.TransactionStateHandler.rollback(TransactionStateHandler.java:165) at com.atomikos.icatch.imp.TransactionStateHandler.rollbackWithStateCheck(TransactionStateHandler.java:180) at com.atomikos.icatch.imp.CompositeTransactionImp.doRollback(CompositeTransactionImp.java:201) at com.atomikos.icatch.imp.CompositeTransactionImp.rollback(CompositeTransactionImp.java:314) at com.atomikos.icatch.jta.TransactionImp.rollback(TransactionImp.java:199) at com.atomikos.icatch.jta.TransactionManagerImp.rollback(TransactionManagerImp.java:426) at com.atomikos.icatch.jta.UserTransactionImp.rollback(UserTransactionImp.java:97)

Any opinion is appreciated,

Hi @coopstah13,

could you publish your code somewhere? it’s a bit hard to understand what is a problem. Regarding the authentication, does it help you if you invoke org.camunda.bpm.engine.IdentityService#setAuthentication(org.camunda.bpm.engine.impl.identity.Authentication) before executing your code?


Unfortunately I don’t think my company would permit me to post my code.

I don’t think what you suggested will help. I’m running an embedded process engine, there should be no authentication, identity management, or authorization at all. The problem is camunda code is trying to get the static reference to the command context in a JTA rollback situation, but it isn’t there. The thing is, my code isn’t even in the stack trace here anyway, other than where it calls the rollback (my servlet filter) which is the previous line from com.atomikos.icatch.jta.UserTransactionImp.rollback(UserTransactionImp.java:97).

Hi @coopstah13,

If you cannot post your code could you prepare a unit test that simulates your situation? I cannot help you further without context of your execution.


1 Like