6 Replies Latest reply on Feb 7, 2011 6:19 PM by Brian Wallis

    When does Session.startProcess() return?

    Brian Wallis Master

      I'm launching a new workflow calling StatefulKnowledgeSession.startProcess() and am wondering about the threading model. When will this return

       

      1) if the first node in the workflow is a rules node and will have to wait for a fact to be inserted into the session

       

      2) if the first node in the workflow is WorkItem node of my own coding, ie: is my code executed by the same thread that called startProcess()

       

      3) if the first node in the workflow is a HumanTask node.

       

      The reason I ask is that I don't know if I need to create a new thread before calling startProcess() or not. And if I do need a thread, how would this be recreated when I want to resume all the workflow sessions after a shutdown? If you can point me at some documentation about the threading and transaction model for jBPM5 I would be very grateful.

       

      thanks,

        • 1. When does Session.startProcess() return?
          Mauricio Salatino Master

          Hi Brain,

          I think that I can explain how a startProcess() method works.

          Ifyou define in your processes nodes that are all executed synchronously,the startProcess() method will execute all the sync activities usingthe same thread that you use to call the startProcess method. It willreturn after all your sync tasks were executed.

           

          Whenyou have async tasks the process will run until the first one andreturn there.So, answering your question 2 and 3, the startProcess()method will return if your workitems are async. Human Tasks workItemsare async by nature, humans are async. If the code inside your customworkitem is sync, that code will be executed in the same thread thatthe startProcess() method was executed.

           

          Ifyou are using rules (question 1) the businessRuleTask will execute ifit find at least one rule activation. and if the engine is in reactivemode (fireUntilHalt) the activation will be automatically executed andyour process will continue.

           

          Trying to answer your last paragraph, you need to know that it depends on the approach that you use:

          But,If you have async tasks, when each of that tasks is completed you willend up having a different thread that will continue the process.

           

          Greetings

          • 2. When does Session.startProcess() return?
            Brian Wallis Master

            Thanks Mauricio,

            That is how I expected it to work (didn't know that HumanTasks were an async execution but it makes sense now that I think about it).

             

            To be safe I think that I should create a new thread to call startProcess() so that the thread executing this call is not potentially delayed for an unknown amount of time (it has other things to do). Some of our Workitem nodes are querying other parts of our system and could be delayed. I was a bit concerned about a build up of the number of threads but in the normal case this is not going to happen, the initial part of most workflows will execute very quickly.

             

            thanks and thanks for all the other documentation/training you are working on. It all helps!

            • 3. When does Session.startProcess() return?
              Brian Wallis Master

              Hi again, a supplementary question if I may...

               

              I am assuming that when I call session.fireAllRules() on a stateless session that it returns when all matching rules have fired and that all of the rules that do fire are executed within the same thread that called session.fireAllRules(). (not really  a jBPM question, just general Drools).

               

              The reason for these questions is that I have worked on more than one system where the thread model was poorly understood and deadlocks and race conditions occured with monotonous (and unpredictable) regularity. I intend to avoid all those problems up front in the design!

               

              thanks.

              • 4. When does Session.startProcess() return?
                Mauricio Salatino Master

                Instead of creating a new thread for each start process you can create your first activity to be asynchronous. You will get the same efect without complicating the threading model of your application.

                • 5. When does Session.startProcess() return?
                  Mauricio Salatino Master

                  About the Drools question, I don't think drools works on the way that you mention.

                  I'm not sure why are you asking about stateless sessions if you are running processes inside the session, you should be working with stateful sessions.

                  Drools works as follow:

                  You insert facts to the working memory. At that point all the rules related with that type of facts are analyzed and activations can be created (if the when part of one rule matches completly). Then when you call the fireAllRules() method, all the activations that were generated will be executed. That execution can cause more activations to be generated. At that point you can have a little bit of recursion caused by the inferences that are being done by the engine, but it shouldn't take too much time. It really depends on your use case, but Drools will not be waiting for matching all the rules blocking your application thread. It will run all the things that it can and after that it will return the control to your application.

                   

                  Hope it helps!

                  Greetings!

                  • 6. When does Session.startProcess() return?
                    Brian Wallis Master

                    Mauricio Salatino wrote:

                     

                    Instead of creating a new thread for each start process you can create your first activity to be asynchronous. You will get the same efect without complicating the threading model of your application.

                    Eventually I hope that the definition and maintenance of the workflows will be by system integrators and even end user system admins so I don't want to have the possibility that an inexperienced workflow developer/maintainer could compromise the system by not having the first activity asynchronous.

                     

                    Mauricio Salatino wrote:

                     

                    I'm not sure why are you asking about stateless sessions if you are running processes inside the session, you should be working with stateful sessions.

                     

                     

                    I plan to have a stateless session for a set of rules that are evaluated over a set of facts (generated by an incoming event from an ESB). These workflow creation rules are quite simple in nature, really just a set of filters for the incoming event to decide what type of workflow is required. The actions in these rules will create a new stateful session from a separate knowledgebase that contains the workflow definitions and then launch the workflow within this new session. So the model is one workflow instance per stateful session rather than one session with many workflow instances.

                     

                    The reason for this is that there is generally very little if any commonality in the facts that each workflow works with and there could be hundreds of workflow instances. The number of facts in a shared session would thus be 100's of times larger than the number of facts that any individual workflow in that shared session would require for its operation. I think this also makes cleanup of old facts easier since when the workflow completes the session is discarded.

                     

                    I hope that this is a reasonable approach. This was the subject of my first post to this forum some weeks ago.