Hi. I'm doing a deep dive into the new jbpm6 PerProcessInstanceRuntimeManager functionality. Impressive. One minor observation is that it seems that both the engine.getKieSession().destroy(); and disposeRuntimeEngine(engine); function calls in the init() <https://github.com/droolsjbpm/jbpm/blob/master/jbpm-runtime-manager/src/m... function are redundant. Neither of these calls seem necessary. Previous to these function calls, an instance of DisposeSessionTransactionSynchronization() was already registered .... which takes care of appropriately disposing the session after the JTA transaction has committed. Subsequently, when either (or both) of these redundant calls to close the session prior to the transaction has committed, the following exception occurs: java.lang.IllegalStateException: Illegal method call. This session was previously disposed. at org.drools.core.reteoo.DisposedReteooWorkingMemory.getProcessRuntime(DisposedReteooWorkingMemory.java:262) [drools-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.core.impl.StatefulKnowledgeSessionImpl.getProcessRuntime(StatefulKnowledgeSessionImpl.java:868) [drools-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.persistence.SingleSessionCommandService$SynchronizationImpl.afterCompletion(SingleSessionCommandService.java:504) [drools-persistence-jpa-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.persistence.jta.JtaTransactionSynchronizationAdapter.afterCompletion(JtaTransactionSynchronizationAdapter.java:22) [drools-persistence-jpa-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402) I'm testing in an EAP6.1 environment using JTA transactions provided by the app server. commenting out those apparently redundant function calls does not seem to cause any other negative side effects and the session is still closed by the DisposeSessionTransactionSynchronization instance. jeff -- Jeffrey Bride Senior Principal Solution Architect Global Partner Enablement Red Hat (www.redhat.com) cell: 303.523.7885 _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

thanks for the explanation. makes sense. i've created this BZ <https://bugzilla.redhat.com/show_bug.cgi?id=996205> . thanks! jeff ------------------------------------------------------------------------ *From: *"Maciej Swiderski" <mswiders(a)redhat.com&gt; *To: *"Jeffrey Bride" <jbride(a)redhat.com&gt; *Cc: *"jbpm-dev" <jbpm-dev(a)lists.jboss.org&gt; *Sent: *Sunday, August 11, 2013 8:19:50 AM *Subject: *Re: [jbpm-dev] dispose sessions in PerProcessInstanceRuntimeManager Jeff, the calls are there to cover cases when the creation of RuntimeManager are not executed as part of an active transaction since only then the transaction synchronization is registered. I guess that in your case you are within container manager transaction and thus tx synchronization is registered which causes the behavior you described. I'll check that to ensure that the init method will not call the dispose/destroy if it's within active transaction. Just for information as that might not be directly clear why the init method creates session and the disposes/destroys it - it is to ensure that start events will be properly initialized - e.g. timer start event based processes will be by that notified and executed according to definitions. Maciej W dniu 09.08.2013 19:17, Jeffrey Bride pisze: Hi. I'm doing a deep dive into the new jbpm6 PerProcessInstanceRuntimeManager functionality. Impressive. One minor observation is that it seems that both the engine.getKieSession().destroy(); and disposeRuntimeEngine(engine); function calls in the init() <https://github.com/droolsjbpm/jbpm/blob/master/jbpm-runtime-manager/src/m... function are redundant. Neither of these calls seem necessary. Previous to these function calls, an instance of DisposeSessionTransactionSynchronization() was already registered .... which takes care of appropriately disposing the session after the JTA transaction has committed. Subsequently, when either (or both) of these redundant calls to close the session prior to the transaction has committed, the following exception occurs: java.lang.IllegalStateException: Illegal method call. This session was previously disposed. at org.drools.core.reteoo.DisposedReteooWorkingMemory.getProcessRuntime(DisposedReteooWorkingMemory.java:262) [drools-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.core.impl.StatefulKnowledgeSessionImpl.getProcessRuntime(StatefulKnowledgeSessionImpl.java:868) [drools-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.persistence.SingleSessionCommandService$SynchronizationImpl.afterCompletion(SingleSessionCommandService.java:504) [drools-persistence-jpa-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.persistence.jta.JtaTransactionSynchronizationAdapter.afterCompletion(JtaTransactionSynchronizationAdapter.java:22) [drools-persistence-jpa-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402) I'm testing in an EAP6.1 environment using JTA transactions provided by the app server. commenting out those apparently redundant function calls does not seem to cause any other negative side effects and the session is still closed by the DisposeSessionTransactionSynchronization instance. jeff -- Jeffrey Bride Senior Principal Solution Architect Global Partner Enablement Red Hat (www.redhat.com) cell: 303.523.7885 _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Hi Maciej. Thanks for implementing the canDestroy() function. I still get the same "session was previously disposed" exception in a JTA environment however this implementation <https://github.com/jbride/jbpm/blob/master/jbpm-runtime-manager/src/main/... of the init() function in the PerProcessInstanceRuntimeManager seems to work. on line 258, seems that getRuntimeEngine(...) function should still be called because it's in that function that the DisposeSessionTransactionSynchronization object is registered. then, using your new canDestroy() function prevents an explicit disposal of the session if a transaction exists (which in my case it does) prior to committing of that transaction. thanks! jeff ------------------------------------------------------------------------ *From: *"Maciej Swiderski" <mswiders(a)redhat.com&gt; *To: *"Jeffrey Bride" <jbride(a)redhat.com&gt; *Cc: *"jbpm-dev" <jbpm-dev(a)lists.jboss.org&gt; *Sent: *Thursday, August 15, 2013 2:09:10 AM *Subject: *Re: [jbpm-dev] dispose sessions in PerProcessInstanceRuntimeManager Jeff, I pushed fix to master, do you mind giving it a try in your setup? Hope it fixes the issue. Thanks Maciej W dniu 12.08.2013 18:15, Jeffrey Bride pisze: thanks for the explanation. makes sense. i've created this BZ <https://bugzilla.redhat.com/show_bug.cgi?id=996205> . thanks! jeff ------------------------------------------------------------------------ *From: *"Maciej Swiderski" <mswiders(a)redhat.com&gt; *To: *"Jeffrey Bride" <jbride(a)redhat.com&gt; *Cc: *"jbpm-dev" <jbpm-dev(a)lists.jboss.org&gt; *Sent: *Sunday, August 11, 2013 8:19:50 AM *Subject: *Re: [jbpm-dev] dispose sessions in PerProcessInstanceRuntimeManager Jeff, the calls are there to cover cases when the creation of RuntimeManager are not executed as part of an active transaction since only then the transaction synchronization is registered. I guess that in your case you are within container manager transaction and thus tx synchronization is registered which causes the behavior you described. I'll check that to ensure that the init method will not call the dispose/destroy if it's within active transaction. Just for information as that might not be directly clear why the init method creates session and the disposes/destroys it - it is to ensure that start events will be properly initialized - e.g. timer start event based processes will be by that notified and executed according to definitions. Maciej W dniu 09.08.2013 19:17, Jeffrey Bride pisze: Hi. I'm doing a deep dive into the new jbpm6 PerProcessInstanceRuntimeManager functionality. Impressive. One minor observation is that it seems that both the engine.getKieSession().destroy(); and disposeRuntimeEngine(engine); function calls in the init() <https://github.com/droolsjbpm/jbpm/blob/master/jbpm-runtime-manager/src/m... function are redundant. Neither of these calls seem necessary. Previous to these function calls, an instance of DisposeSessionTransactionSynchronization() was already registered .... which takes care of appropriately disposing the session after the JTA transaction has committed. Subsequently, when either (or both) of these redundant calls to close the session prior to the transaction has committed, the following exception occurs: java.lang.IllegalStateException: Illegal method call. This session was previously disposed. at org.drools.core.reteoo.DisposedReteooWorkingMemory.getProcessRuntime(DisposedReteooWorkingMemory.java:262) [drools-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.core.impl.StatefulKnowledgeSessionImpl.getProcessRuntime(StatefulKnowledgeSessionImpl.java:868) [drools-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.persistence.SingleSessionCommandService$SynchronizationImpl.afterCompletion(SingleSessionCommandService.java:504)[drools-persistence-jpa-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at org.drools.persistence.jta.JtaTransactionSynchronizationAdapter.afterCompletion(JtaTransactionSynchronizationAdapter.java:22)[drools-persistence-jpa-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT] at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402) I'm testing in an EAP6.1 environment using JTA transactions provided by the app server. commenting out those apparently redundant function calls does not seem to cause any other negative side effects and the session is still closed by the DisposeSessionTransactionSynchronization instance. jeff -- Jeffrey Bride Senior Principal Solution Architect Global Partner Enablement Red Hat (www.redhat.com) cell: 303.523.7885 _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev