[jbpm-dev] dispose sessions in PerProcessInstanceRuntimeManager
Jeffrey Bride
jbride at redhat.com
Mon Aug 12 12:15:45 EDT 2013
thanks for the explanation. makes sense.
i've created this BZ .
thanks! jeff
----- Original Message -----
> From: "Maciej Swiderski" <mswiders at redhat.com>
> To: "Jeffrey Bride" <jbride at redhat.com>
> Cc: "jbpm-dev" <jbpm-dev at lists.jboss.org>
> 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() 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20130812/558bc4d8/attachment.html
More information about the jbpm-dev
mailing list