Hide Forgot
project_key: SOA Attached is a little modified bpm_orchestration quickstart (printlns commented out and added the ability to send multiple start messages with multiple threads). The process definition is the same. Steps to reproduce: 1.) unzip SOA-P 2.) configure SOA-P using schema tool to Oracle10g 3.) start SOA-P up 4.) unzip attached bpm_orchestration2.zip (QS) into ${SOA-P}/jboss-as/samples/quickstarts directory 5.) from QS dir execute: $ ant deploy $ ant deployProcess $ ant startProcess -Dthreads=1 -Dcount=5000 6.) wait like 15-20 minutes and followin SOSE starts to appear. It eventualy floods the server's log with ERROR entries. 10:34:01,682 ERROR [AbstractFlushingEventListener] 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.context.exe.TokenVariableMap#19618] at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1783) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2426) at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2326) at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2626) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168) 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:1029) at org.jboss.soa.esb.services.jbpm.integration.command.AbstractMessageListener.onMessage(AbstractMessageListener.java:77) at org.jboss.soa.esb.services.jbpm.integration.command.JobListener.onMessage(JobListener.java:16) at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.internal.soa.esb.dependencies.JCAInflowAdapter$1.invoke(JCAInflowAdapter.java:276) at org.jboss.soa.esb.listeners.jca.EndpointProxy.delivery(EndpointProxy.java:258) at org.jboss.soa.esb.listeners.jca.EndpointProxy.invoke(EndpointProxy.java:150) at $Proxy319.onMessage(Unknown Source) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:179) at org.jboss.jms.client.container.ClientConsumer.callOnMessageStatic(ClientConsumer.java:160) at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:831) at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleRun_587199138.invoke(SessionAspect_z_handleRun_587199138.java) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java) at org.jboss.jms.client.JBossSession.run(JBossSession.java:199) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:236) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)
Attached bpm_orchestration2.zip quickstart for issue reproduction.
Attachment: Added: bpm_orchestration2.zip
The conflict is happening on the parent token and not those which are executing, apparently as a result of creating the process instance variables during the subflows. The process definition needs to create the instance variables before the fork occurs.
The following shows the issue occurring Thread WorkManager(2)-48 2011-01-24 12:03:46,138 115312 DEBUG [knrc.jdbc.JDBCTrackerPreparedStatement] (WorkManager(2)-48:) Tracker calling from executeUpdate(), sql is: insert into JBPM_VARIABLEINSTANCE (ID_, VERSION_, NAME_, CONVERTER_, TOKEN_, TOKENVARIABLEMAP_, PROCESSINSTANCE_, STRINGVALUE_, CLASS_) values (null, ?, ?, ?, ?, ?, ?, ?, 'S') param[1] = '0' param[2] = 'theBody_LA' param[3] = 'null' param[4] = '20015' param[5] = '20015' param[6] = '5015' param[7] = 'Getting Started 'Receive Order' 'Credit Check' 'Validate Order' 'Inventory Check' 'Los Angeles' ' 2011-01-24 12:03:46,138 115312 DEBUG [knrc.jdbc.JDBCTrackerPreparedStatement] (WorkManager(2)-48:) Tracker calling from executeUpdate(), sql is: update JBPM_TOKEN set VERSION_=?, NAME_=?, START_=?, END_=?, NODEENTER_=?, NEXTLOGINDEX_=?, ISABLETOREACTIVATEPARENT_=?, ISTERMINATIONIMPLICIT_=?, ISSUSPENDED_=?, LOCK_=?, NODE_=?, PROCESSINSTANCE_=?, PARENT_=?, SUBPROCESSINSTANCE_=? where ID_=? and VERSION_=? param[1] = '3' param[2] = 'to Los Angeles WHSE' param[3] = '2011-01-24 11:58:40.302' param[4] = '2011-01-24 12:03:46.128' param[5] = '2011-01-24 12:03:46.135' param[6] = '0' param[7] = 'false' param[8] = 'false' param[9] = 'false' param[10] = '<null>' param[11] = '8' param[12] = '5015' param[13] = '20015' param[14] = '<null>' param[15] = '20435' param[16] = '2' 2011-01-24 12:03:46,139 115313 DEBUG [knrc.jdbc.JDBCTrackerPreparedStatement] (WorkManager(2)-48:) Tracker calling from executeUpdate(), sql is: update JBPM_TOKENVARIABLEMAP set VERSION_=?, TOKEN_=?, CONTEXTINSTANCE_=? where ID_=? and VERSION_=? param[1] = '10' param[2] = '20015' param[3] = '10029' param[4] = '20015' param[5] = '9' Thread WorkManager(2)-51 2011-01-24 12:03:46,167 115341 DEBUG [knrc.jdbc.JDBCTrackerPreparedStatement] (WorkManager(2)-51:) Tracker calling from executeUpdate(), sql is: insert into JBPM_VARIABLEINSTANCE (ID_, VERSION_, NAME_, CONVERTER_, TOKEN_, TOKENVARIABLEMAP_, PROCESSINSTANCE_, STRINGVALUE_, CLASS_) values (null, ?, ?, ?, ?, ?, ?, ?, 'S') param[1] = '0' param[2] = 'theBody_Dallas' param[3] = 'null' param[4] = '20015' param[5] = '20015' param[6] = '5015' param[7] = 'Getting Started 'Receive Order' 'Credit Check' 'Validate Order' 'Inventory Check' 'Dallas' ' 2011-01-24 12:03:46,168 115342 DEBUG [knrc.jdbc.JDBCTrackerPreparedStatement] (WorkManager(2)-51:) Tracker calling from executeUpdate(), sql is: update JBPM_TOKEN set VERSION_=?, NAME_=?, START_=?, END_=?, NODEENTER_=?, NEXTLOGINDEX_=?, ISABLETOREACTIVATEPARENT_=?, ISTERMINATIONIMPLICIT_=?, ISSUSPENDED_=?, LOCK_=?, NODE_=?, PROCESSINSTANCE_=?, PARENT_=?, SUBPROCESSINSTANCE_=? where ID_=? and VERSION_=? param[1] = '3' param[2] = 'to Dallas WHSE' param[3] = '2011-01-24 11:58:40.301' param[4] = '2011-01-24 12:03:46.147' param[5] = '2011-01-24 12:03:46.148' param[6] = '0' param[7] = 'false' param[8] = 'false' param[9] = 'false' param[10] = '<null>' param[11] = '8' param[12] = '5015' param[13] = '20015' param[14] = '<null>' param[15] = '20434' param[16] = '2' 2011-01-24 12:03:46,168 115342 DEBUG [knrc.jdbc.JDBCTrackerPreparedStatement] (WorkManager(2)-51:) Tracker calling from executeUpdate(), sql is: update JBPM_TOKENVARIABLEMAP set VERSION_=?, TOKEN_=?, CONTEXTINSTANCE_=? where ID_=? and VERSION_=? param[1] = '10' param[2] = '20015' param[3] = '10029' param[4] = '20015' param[5] = '9' The TokenVariableMap of the parent token is updated in both threads, as a result of the creation of the variable instances.
Assigning back to Pavel
I modified (and attached) the process definition that fixes the SOSE issue.
Attachment: Added: processdefinition.xml
We need to include some documentation around these requirements.
Handing this one to you because it's jBPM related and it is possibly material that should be added into their upstream docs as well as ours. To me it seems like this would be <important> "you must do Y before doing X when doing a Z or you will get this type of error" thing to add into the docs when Z is being discussed. I think the QuickStart being referred to here is just a instance of it. If they don't fix the quickstart we will also need to document it as a known issue for the quickstart. Please: 1) clarify what the issue is, 2) where is the best place to call it out in the jBPM guide, 3) will the quickstart be fixed for 5.1, 4) if it also applies to upstream jBPM, 5) and document as required
Kev, just chasing this one up. Have you created documentation for this in the proj docs? If so I will merge it into the product ones. If not, can you outline exactly what we need to document (dot points are fine) and I will write it. Thanks.
David, this needs to go in the jBPM documentation but should be something like the following When using process instance variables within a process definition it is important to realise that the initial creation of the variable is a point at which there will exist contention with other tokens which may also be creating variables. This contention will result in the persistence layer throwing StaleObjectStateExceptions, causing the encompassing transaction to be rolled back and retried. In order to avoid this point of contention it is important that all instance variables are initialised before the process definition introduces any concurrency, e.g. through the use of a fork.
Added the paragraphs suggested by Kevin.
Release Notes Docs Status: Added: Not Required