-
1. Re: Questions about transactions in jBPM 4.3
rebody Jun 12, 2010 10:53 PM (in response to rhodos)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 Jun 14, 2010 5:32 PM (in response to rebody)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 Jun 14, 2010 9:32 PM (in response to rhodos)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.