Situation:

• On engine startup, the history cleanup job is re-configured according to updated cleanup settings
• This may fail with an optimistic locking exception if the job is currently executed or if another engine does the same in a cluster
• With CAM-8866 we fixed that this exception is not propagated but only logged

Current behavior:

• On weblogic, the cleanup re-configuration failure is logged; however, the cleanup job is re-configured in the context of a container-managed transaction, which is then set to rollback-only
• Subsequently, when the transaction is supposed to be committed, it fails
• Apparently, the process engine is then not available in the container and subsequent process application deployments fail as well

Expected behavior:

• The re-configuration failure is logged, but other than that platform startup should not be affected

Details:

• see log files for exceptions
• I reproduced this by remotely debugging an integration test and artificially creating an instance of OptimisticLockingException in CommandContext#close. This exception is then rethrown which creates the same situation as if there was an actual optimistic locking problem.
• You can configure Weblogic for remote debugging by adding the entry <property name="jvmOptions">-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y</property> to arquillian.xml
• I did not yet understand why the failure of the managed transaction also results in the process engine not being available in the container
• I was a bit surprised to see a managed transaction here, since EjbBpmPlatformBootstrap is annotated with @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED), but I guess that I just don't have that level of Java-EE-fu