3 Replies Latest reply on Jun 14, 2010 9:32 PM by rebody

    Questions about transactions in jBPM 4.3

    rhodos

      Hi,

       

      I am confused about the meaning of 'transaction' in the context of jBPM 4.3.  My understanding is that it saves the current state of the process instance to a database.  Is this correct?  However, the user guide says that when an asynchronous continuation is placed on an element of the pd, that element is executed in a new transaction.  Does this somehow obscure the persisted state of the process?

       

      Thanks,

      Rachel

        • 1. Re: Questions about transactions in jBPM 4.3
          rebody

          Hi Rachel,

           

          jBPM 4 simply use one thread to execute all of automatic activities in an execution.  If the execution arrival a wait activity, like State, Task or SubProcess, the execution will turn to wait state and operation will return, the related transaction will commit.

           

          And the Async Message is a way to return the operation result immediately,  it won't wait for the all of operations of an execution.  It is useful for time cost operations.  For example, If you want to generate some reports in an activity, and this operation will take lots of time,  then you could use continue="async", and processEngine will tell end user that the reports are generating, they could continue to do other jobs.  So it needn't let user wait for all of jobs completed.  They could get the return message information directly.

           

          In jBPM 4, the async message is handled by the JobExecutor.  You can think it just like a Thread.  It will go on query the database, if there are some jobs, it will take the job, and execute them.  Because the JobExecutor will start individual transaction to handle these jobs.  So we said that the transaction that async messages executed is different from the user request.

           

          Hope it will helpful.

          • 2. Re: Questions about transactions in jBPM 4.3
            rhodos

            HuiSheng,

             

            Thanks for your response.  I am still a bit confused, though.

             

            What do you mean when you say that "the JobExecutor will start individual transactions to handle these jobs"?  Does a separate transaction mean that the information will be stored in a separate location?

             

            Also, are you saying that every activity with an async continuation is executed in its own thread?  If so, is there any chance of activities being executed out of order?  In other words, in a pd: A-B-C (all async), could B start before A finishes?  I've tested this and the answer seems to be 'no,' but I just want to be sure that this could never happen.

             

            Thanks again,

            Rachel

            • 3. Re: Questions about transactions in jBPM 4.3
              rebody

              Hi Rachel,

              What do you mean when you say that "the JobExecutor will start  individual transactions to handle these jobs"?
              Does a separate  transaction mean that the information will be stored in a separate  location?

               

              JobExecutor may have more than a thread to handle the waiting jobs.  By default, each of thread could handle one job.  Each of them will execute in a separate transaction.

              The information of jobs are stored in the JBPM4_JOB table.  When one of them was picked by jobExecutor,  JobExecutor will lock it and try to execute it in a transaction.  If Jobexecutor can successly complete this job, it will delete the related job information from database, and try to pick another job.  If these were some exceptions occurs, JobExecutor will store the exception information and try to execute the job again.

               

              Also, are you saying that every activity with an async continuation is  executed in its own thread?  If so, is there any chance of activities  being executed out of order?  In other words, in a pd: A-B-C (all  async), could B start before A finishes?  I've tested this and the  answer seems to be 'no,' but I just want to be sure that this could  never happen.

               

              Yes.  If you use fork to create multiply path of async executions,  then you cannot tell which execution will be executed first,  which one will be executed second.

               

              But as you said that your process definition is sequence,  there is no parallal paths.  So when process arrivalled activity A,  it will create a async job and return.  At that moment, there was only one job for activity A.  Until Jobexecutor finished this job, the process will not arrivalled other activities, so there will be no more jobs be created.  When jobExecutor finished the job of activity A,  then process will continue, and arrivalled activity B then return.  The job of activity B will be created and waited jobExecutor to execute.  So You needn't worry about the order of sequence process.

               

              Hope this will be some help.