[jbpm-dev] dispose sessions in PerProcessInstanceRuntimeManager
Maciej Swiderski
mswiders at redhat.com
Fri Aug 16 05:14:41 EDT 2013
Jeff, could you please share the complete stacktrace for further
investigation?
Thanks
Maciej
W dniu 15.08.2013 16:46, Jeffrey Bride pisze:
>
> 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/java/org/jbpm/runtime/manager/impl/PerProcessInstanceRuntimeManager.java#L258>
> 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 at redhat.com>
> *To: *"Jeffrey Bride" <jbride at redhat.com>
> *Cc: *"jbpm-dev" <jbpm-dev at lists.jboss.org>
> *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 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()
> <https://github.com/droolsjbpm/jbpm/blob/master/jbpm-runtime-manager/src/main/java/org/jbpm/runtime/manager/impl/PerProcessInstanceRuntimeManager.java#L261>
> 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/20130816/58e96a41/attachment.html
More information about the jbpm-dev
mailing list