11 Replies Latest reply on Aug 18, 2008 3:06 PM by petia

    Stale state problem kills process instance?

    msandoz

      I've set up JBPM with the web console and a datasource pointing to a postgres installation.

      Everything works fine and I can execute flows except for instances like this one which specifically does not work for me:

      Start->Fork
       | \
       Node1 Node2
       \ /
       Join
       |
       End
      
      


      Nodes 1 and 2 (this is the simplest case i could come up with though i have others that are more complex) are completely unconfigured, meaning no events, action or exception handlers on them. and nothing is set to asynchronous.

      heres the error i get in the web console:

      Error starting process: An exception of type "org.hibernate.StaleObjectStateException" was thrown. The message is: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#5672]


      I tried wiping out the rest of the processes in the database, tried every transaction isolation level in the datasource, restarting the app server etc. this is BTW running on 4.0.5GA and the latest JBPM from cvs.

      I added considerably to the logging and still can not see the stack trace of an exception anywhere in the log. When this happens it does not create an instance of the process - or if it does it rolls it back. without a stack trace its hard to figure out whats going on...

        • 1. Re: Stale state problem kills process instance?
          msandoz

          I was continuing to simplify this case and took out first one node and then the other - resulting in:

          Start
           |
          Fork
           |
          Join
           |
           End
          


          and am continuing to have the same error. So far, flows with no fork seem to work.

          These are other related results:

          S=start;F=Fork;FA=asynch fork;N=node;NA=asynch node;J=join;E=end
          S--F--J--E STALE
          S--FA--J--E NO ERROR
          S--F--N--J--E STALE
          S--FA--N--J--E NO ERROR
          S--FA--(N1, N2)--J--E NPE as below
          S--FA--(NA1, NA2)--J--E NPE as below
          

          HTTP Status 500 -
          
          type Exception report
          
          message
          
          description The server encountered an internal error () that prevented it from fulfilling this request.
          
          exception
          
          javax.servlet.ServletException
           javax.faces.webapp.FacesServlet.service(FacesServlet.java:256)
           org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
          
          root cause
          
          java.lang.NullPointerException
           java.lang.String.compareTo(String.java:998)
           java.lang.String.compareTo(String.java:90)
           org.jboss.gravel.data.action.SortActionListener$ELComparator.compare(SortActionListener.java:144)
           java.util.Arrays.mergeSort(Arrays.java:1284)
           java.util.Arrays.sort(Arrays.java:1223)
           java.util.Collections.sort(Collections.java:159)
           edu.emory.mathcs.backport.java.util.Collections.sort(Collections.java:31)
           org.jboss.gravel.data.action.SortActionListener.processAction(SortActionListener.java:83)
           javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)
           javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)
           javax.faces.component.UICommand.broadcast(UICommand.java:368)
           org.jboss.gravel.action.handler.ResponseActionsHandler.onComponentPopulated(ResponseActionsHandler.java:24)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:180)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           org.jboss.gravel.common.handler.CollectionHandler.applyNextHandler(CollectionHandler.java:155)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
           com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
           com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143)
           com.sun.facelets.tag.ui.DecorateHandler.apply(DecorateHandler.java:105)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:314)
           com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:169)
           com.sun.facelets.tag.ui.DefineHandler.apply(DefineHandler.java:58)
           com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:128)
           com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:306)
           com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:279)
           com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
           com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
           com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
           com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143)
           com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:113)
           com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
           com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
           com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
           com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:143)
           com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:113)
           com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
           com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:25)
           com.sun.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:95)
           com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:503)
           com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:546)
           javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:178)
           com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
           com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
           com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
           javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
           org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
          
          note The full stack trace of the root cause is available in the Apache Tomcat/5.5.20 logs.
          Apache Tomcat/5.5.20
          


          • 2. Re: Stale state problem kills process instance?
            koen.aers

            Matthew,

            Can you create a unit test that shows this problem and attach it to a JIRA issue?

            Cheers,
            Koen

            • 3. Re: Stale state problem kills process instance?
              msandoz

              We're working on reproducing this in the simplest manner possible. so far it seems not to happen on HSQL.

              i didnt want to add it in as a jira ticket until i was sure it wasnt just a configuration blunder.

              here are the steps we took though to reproduce the issue:

              1. jbpm 3.2.1 deployed from the available EAR onto JBoss AS 4.0.5GA (on another machine we just have the console war and the behaviour is the same)
              2. postgres 8.2
              3. JDK 1.5
              4. standard postgres jbpm-ds.xml
              5. deploy the process, literally, Start->Fork->Join->End
              6. start an instance from the web console

              We got a stacktrace with the remote debugger as below. The error seems to be that it is trying to update the version of the parent token using lock while it is executing the join. the hibernate code in the trace is trying to execute an update to increment the version of the token and receiving a 0 record count from the update. it thinks that means that the where clause failed and therefore it's looking for an obsolete version to update.

              if you still think this may be a bug as opposed to misconfiguration, i will enter a jira ticket for it.

              14:21:56,810 ERROR [STDERR] org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#41]
              
               at org.hibernate.persister.entity.AbstractEntityPersister.forceVersionIncrement(AbstractEntityPersister.java:1191)
              
               at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:82)
              
               at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64)
              
               at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584)
              
               at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576)
              
               at org.jbpm.graph.node.Join.execute(Join.java:110)
              
               at org.jbpm.graph.def.Node.enter(Node.java:318)
              
               at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
              
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              
               at java.lang.reflect.Method.invoke(Method.java:585)
              
               at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:185)
              
               at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$205a4b1d.enter(<generated>)
              
               at org.jbpm.graph.def.Transition.take(Transition.java:151)
              
               at org.jbpm.graph.def.Node.leave(Node.java:393)
              
               at org.jbpm.graph.def.Node.leave(Node.java:357)
              
               at org.jbpm.graph.node.Fork.execute(Fork.java:142)
              
               at org.jbpm.graph.def.Node.enter(Node.java:318)
              
               at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
              
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              
               at java.lang.reflect.Method.invoke(Method.java:585)
              
               at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:185)
              
               at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$205a4b1d.enter(<generated>)
              
               at org.jbpm.graph.def.Transition.take(Transition.java:151)
              
               at org.jbpm.graph.def.Node.leave(Node.java:393)
              
               at org.jbpm.graph.node.StartState.leave(StartState.java:70)
              
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              
               at java.lang.reflect.Method.invoke(Method.java:585)
              
               at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:185)
              
               at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$205a4b1d.leave(<generated>)
              
               at org.jbpm.graph.exe.Token.signal(Token.java:194)
              
               at org.jbpm.graph.exe.Token.signal(Token.java:165)
              
               at org.jbpm.jsf.core.action.StartProcessActionListener.handleAction(StartProcessActionListener.java:70)
              
               at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82)
              
               at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)
              
               at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)
              
               at javax.faces.component.UICommand.broadcast(UICommand.java:368)
              
               at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448)
              
               at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
              
               at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
              
               at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
              
               at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
              
               at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
              
               at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
              
               at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
              
               at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
              
               at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
              
               at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
              
               at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
              
               at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
              
               at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
              
               at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
              
               at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
              
               at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
              
               at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
              
               at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
              
               at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
              
               at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
              
               at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
              
               at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
              
               at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
              
               at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
              
               at java.lang.Thread.run(Thread.java:595)
              


              • 4. Re: Stale state problem kills process instance?
                msandoz
                • 5. Re: Stale state problem kills process instance?
                  supterlobster

                  I have the similar problem with hibernate323, jbpm321, jboss420.


                  2007-07-30 23:14:20,714 5742606 ERROR [com.rrd.pmt.workflow.service.Task] (pool-6-thread-1:)
                  org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.graph.exe.Token#11804]
                  at org.hibernate.persister.entity.AbstractEntityPersister.forceVersionIncrement(AbstractEntityPersister.java:1235)
                  at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:82)
                  at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64)
                  at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584)
                  at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576)
                  at org.jbpm.graph.node.Join.execute(Join.java:109)
                  at org.jbpm.graph.def.Node.enter(Node.java:318)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                  at java.lang.reflect.Method.invoke(Method.java:585)
                  at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                  at org.jbpm.graph.def.Node_$$_javassist_544.enter(Node_$$_javassist_544.java)
                  at org.jbpm.graph.def.Transition.take(Transition.java:151)
                  at org.jbpm.graph.def.Node.leave(Node.java:393)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                  at java.lang.reflect.Method.invoke(Method.java:585)
                  at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173)
                  at org.jbpm.graph.def.Node_$$_javassist_544.leave(Node_$$_javassist_544.java)
                  at org.jbpm.graph.exe.Token.signal(Token.java:194)
                  at org.jbpm.graph.exe.Token.signal(Token.java:139)
                  at com.rrd.pmt.workflow.service.AbstractTaskExecutorService.doTranstion(AbstractTaskExecutorService.java:123)
                  at com.rrd.pmt.workflow.service.Task.run(Task.java:40)
                  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
                  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
                  at java.util.concurrent.FutureTask.run(FutureTask.java:123)
                  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
                  at java.lang.Thread.run(Thread.java:613)


                  The strange thing is if I use ejb timers to execute all the fork steps, everything is fine. However, if driving one of the fork steps with external jbpmconfigure, although still using the same hibernate session factory as other timers steps, it will have this error, my external jbpmconfig code looks like:

                  caller:
                  
                  public void doTranstion(long id, String tokenPath, String path) throws Exception {
                   JbpmContext jbpmContext = JbpmUtil.getJbpmConfig().createJbpmContext();
                   try {
                   ProcessInstance processInstance = jbpmContext.loadProcessInstanceForUpdate(id);
                   if (processInstance == null) {
                   logger.debug("ProcessInstance " + id + " does not exist anymore. Ignore it");
                   return;
                   }
                  
                   Token token = processInstance.findToken(tokenPath);
                   logger.info("ProcessIntance " + processInstance.getId() + " changing from node[" + token.getNode().getDefaultLeavingTransition().getFrom().getName() + "] to node["
                   + token.getNode().getDefaultLeavingTransition().getTo().getName() + "]" + ". File=" + path);
                   token.signal();
                   } catch (Exception e) {
                   logger.error("", e);
                   throw e;
                   } finally {
                   jbpmContext.close();
                   }
                   }
                  
                  
                  
                  public class JbpmUtil {
                   static Logger logger = Logger.getLogger(JbpmUtil.class);
                   static private JbpmConfiguration jbpmConfiguration = null;
                  
                   synchronized static public JbpmConfiguration getJbpmConfig() {
                   if (jbpmConfiguration == null) {
                   jbpmConfiguration = JbpmConfiguration.getInstance("jbpm.cfg.xml");
                   }
                  
                   return jbpmConfiguration;
                   }
                  ...}



                  Using treecache with serializable isolation. Token used in the code is retrieved from
                  ExecutionContext.getToken().getFullName();

                  Still wondering what is difference here? Should treecache take care this?

                  • 6. Re: Stale state problem kills process instance?

                    I'm having the same problem. Apparantly having wait states or not in the child paths (tokens) makes a difference.

                    If in the child paths the process must wait (until it is signalled again) then I see in the database 3 tokens: root, child 1 and child 2.

                    If the complete process, including the child paths, runs to completion with one signal() then I see in the database only 2 tokens: root and a child.

                    I'm wondering if the 2nd child token is not reusing the record of the 1st token in some way?

                    • 7. Re: Stale state problem kills process instance?
                      petia

                      Hi,

                      I am running jBPM 3.2.3 out-of-the-box (with Java 1.6). I got the same problem as described above.
                      Coincidentally, I discovered that if both transitions outgoing from the Fork have the attribute "name" set the problem does not appear (the default setting is that the first transition does not have this attribute set to anything).

                      Kind regards, Petia

                      • 8. Re: Stale state problem kills process instance?

                        You probably have a race condition between the beginning of the async node finishing up, and the end of the async firing. I wasn't clear on what's causing the wait node to complete - can it be very quick? If so, try putting a delay in there and see if it goes away.

                        This isn't a fix, obviously - it just will point a finger at the problem.

                        -Ed

                        • 9. Re: Stale state problem kills process instance?
                          petia

                          Hi Ed,

                          Below is the example which works nicely for me. Note that, the fork and join have the default setting async="false". The transitions "to B1" and "to B2" going out from the Fork node, do not have any conditions specified. The only difference of this example, from a non-working example is that both transitions going out from the Fork node have names, i.e. "to B1" and "to B2" below.

                          I hope this helps, Petia

                          <?xml version="1.0" encoding="UTF-8"?>
                          
                          <process-definition xmlns="urn:jbpm.org:jpdl-3.2" name="Fork">
                           <swimlane name="Initiator">
                           <assignment actor-id="admin"></assignment>
                           </swimlane>
                          
                           <start-state name="start-state1">
                           <task name="start-task" swimlane="Initiator"></task>
                           <transition to="taskA"></transition>
                           </start-state>
                          
                           <task-node name="taskA">
                           <task name="taskA" swimlane="Initiator"></task>
                           <transition to="fork1"></transition>
                           </task-node>
                          
                           <fork name="fork1">
                           <transition to="taskB1" name="to B1"></transition>
                           <transition to="taskB2" name="to B2"></transition>
                           </fork>
                          
                           <task-node name="taskB1">
                           <task name="taskB" swimlane="Initiator"></task>
                           <transition to="join1"></transition>
                           </task-node>
                          
                           <task-node name="taskB2">
                           <task swimlane="Initiator" name="taskB2"></task>
                           <transition to="join1"></transition>
                           </task-node>
                          
                           <join name="join1">
                           <transition to="end-state1"></transition>
                           </join>
                          
                           <end-state name="end-state1"></end-state>
                          </process-definition>


                          • 10. Re: Stale state problem kills process instance?

                            Petia,
                            If you have async=false on everything, all the work is performed sequentially on one thread - there's no opportunity for a stale object (or race condition) to occur.
                            -Ed

                            • 11. Re: Stale state problem kills process instance?
                              petia

                              Hi Ed,

                              Thanks for your reply. Maybe I misunderstood you, but I do not set the attribute async to anything at all. According to the specification, this attribute default value is "false". In my opinion this is a strange attribute to have for a Fork Node, but again according to the specification every Node has it.

                              So, without setting the async attribute and by using a Fork Node, I get a parallel split and the activities following the Fork Node are enabled (and possible to execute) in parallel. Nothing strange here.

                              Sorry, if I comments have caused confusion. The problem mentioned initially was that the engine sometimes generates an error message when Fork is used (and breaks down, i.e., a restart is needed). I observed that it only happens if one of the outgoing transitions from a Fork misses a name (which is the default setting). Note, that this is just an observation based on a problem I faced and a couple of examples I was running. I have not made any real "trouble shooting" of the problem. I just though my observation can help others.

                              Regards, Petia