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