[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