-
Feature Request
-
Resolution: Done
-
Major
-
jBPM 5.3
-
None
Assume that you have multiple threads which take care of its own ksession and process instance. So you can expect that process instances are isolated. But StaleObjectStateException occurs.
2012-08-07 16:25:41,570 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (http-0.0.0.0-8080-5) Could not synchronize database state with session
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#8]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2425)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2325)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2625)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:278)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:262)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1030)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:367)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:504)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:101)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:272)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:89)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:160)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1433)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:162)
at org.drools.persistence.jta.JtaTransactionManager.commit(JtaTransactionManager.java:179)
at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:359)
at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.fireAllRules(CommandBasedStatefulKnowledgeSession.java:249)
Kris:
> Yes, if your process instances are sharing the same signal (e.g. same
> rule flow group or same signal event), if you send the signal to one
> session it can load process instances started on another session. This
> is wanted / expected behaviour in some cases, but if you want to keep
> both session separate, it would probably be a good idea to configure the
> session to only load process instances that were started by that session.
> This would require an extension of the current implementation to:
> - also store the session id (that created the process instance) as
> part of the session info
> - allow the user to configure that it should only load process
> instances for that session (with updated query)
- relates to
-
JBPM-3594 Improve the way signaling of an event on a session works by only dispatching the event occurrence to the processes that were created in that session, and not to process instances created in other sessions
-
- Open
-