Description of problem: Seems the start of process is not persisted because if I perform the steps below, the process instance is still active in ksession. #begin of transaction #start of process #rollback #dispose runtime manager #create runtime manager with the same identifier to reload the persisted ksession (BTW strategy is SINGLETON) #get process instance #check that the process instance is null -- here is the problem because the process instance isn't null Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 796426 [details] StartProcessRollbackTest Attached StartProcessRollbackTest. The test uses JbpmJUnitBaseTestCase, so you should be able to test it in jbpm-test module or somewhere you have access to the module. Also use any process definition which stay active after start (e.g. containing a human task)
the reason why the process instance is not rolled back as expected is due to user transaction instance is not the right one: UserTransaction ut = com.arjuna.ats.jta.UserTransaction.userTransaction(); arjuna transaction is not used in junit testing and thus it will give instance that is not used by the runtime service. With that said even though you call rollback the engine when executing process isntance does not find any active transaction and thus commit it on the end of startProcess operation. To make your test work properly you should replace the line above with: UserTransaction ut = InitialContext.doLookup("java:comp/UserTransaction"); could you please confirm?
Hi Maciej, thank you, I recycled the tests for transactions from BRMS 5.x, so has this changed meantime? After the change to use InitialContext.doLookup("java:comp/UserTransaction"); the test works.
Ivo, thanks for confirmation. As far as I can tell, nothing has changed in this regard. JUnit tests were always relying on UserTransaction taken from JNDI and never used arjuna for any sort of transaction operations. bitronix is used in tests and it does bind UserTransaction into JNDI. I believe then this issue can be closed, wdyt?
Then I have no idea how it appeared there :). Yes, we can close it since there is nothing to be fixed.