-
1. Re: JBPM - concurrent process execution fails
efip10 Jul 12, 2007 11:30 AM (in response to efip10)Forgot to mention: there are no tasks, joins/forks, or child processes used in my flow. It is really, really simple continuous flow.
-
2. Re: JBPM - concurrent process execution fails
kukeltje Jul 12, 2007 11:45 AM (in response to efip10)what in your view is a simple continous flow, is in fact straight trough processing. BUT.... with influences from external systems. This is an issue currently under debate/investigation.
Saving the process before reading it is done when closing the context. So the sooner you do that, the sooner you can read it again in other systems. -
3. Re: JBPM - concurrent process execution fails
estaub Jul 12, 2007 12:17 PM (in response to efip10)I'm not sure, but I think that if you mark your message-firing node as 'asynch="true"', this will force a commit and take care of the problem.
If you happen to be firing the message from the node-entry event, this won't work; you'll need to mark a prior node, perhaps introducing a dummy one just for this purpose.
-Ed Staub -
4. Re: JBPM - concurrent process execution fails
kukeltje Jul 12, 2007 12:47 PM (in response to efip10)Ed,
Will putting an async=true on the node realy force a commit? That has to be documented well then (rollback
's further on in the process a rollback will not be possible then) This is not a problem if the process has to wait for the return value of the async message node.
If it is not saved with async=true and I'm not sure, the result of this async action is to return *before* there is a real save, we get the other 'well known ;-)' exceptions. -
5. Re: JBPM - concurrent process execution fails
efip10 Jul 15, 2007 6:23 AM (in response to efip10)Thanks for the replies, guys.
I tried to put async=true on all of my message-firing nodes, and actually that does not help. I can see in the log that context.close() is finished after the message arrives and the instance is loaded.
Except for using a voluntary Thread.sleep(), does anyone have an idea of how I can make sure the process has finished the commit? -
6. Re: JBPM - concurrent process execution fails
efip10 Jul 15, 2007 1:31 PM (in response to efip10)FYI guys, in the meantime I have a workaround of using
ctx.getJbpmContext().save(ctx.getProcessInstance())
in my action - before sending a message; all this works only because of @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) on MDB, so every save() also commits.
I am not sure whether this might be a solution for everyone (I am sure it wouldn't), so it'd be nice if a call to loadProcessInstance() would not return until the instance is in some steady state. -
7. Re: JBPM - concurrent process execution fails
estaub Jul 15, 2007 8:12 PM (in response to efip10)"kukeltje" wrote:
Ed,
Will putting an async=true on the node realy force a commit? That has to be documented well then (rollback
's further on in the process a rollback will not be possible then) This is not a problem if the process has to wait for the return value of the async message node.
Ronald,
Take a look at Node.enter():// execute the node
if (isAsync) {
ExecuteNodeJob job = createAsyncContinuationJob(token);
MessageService messageService = (MessageService) Services.getCurrentService(Services.SERVICENAME_MESSAGE);
messageService.send(job);
token.lock(job.toString());
} else {
execute(executionContext);
}
So yeah, I think it leads to a commit.
Unfortunately, as efip10 found out, there's a race condition between the commit and the new job.
-Ed Staub -
8. Re: JBPM - concurrent process execution fails
koen.aers Jul 16, 2007 3:28 AM (in response to efip10)efib10,
can you post the details of your processdefinition and your client code? we are investigating these serious concurrency issues that exist in jBPM at the moment. There are two failing jUnit tests in the org.jbpm.job.executor package (JobLoadJoinTest and JobLoadSubprocessTest). As you know debugging and analysing these type of problems is very painful, so we need all the possible info we can get.
Thanks,
Koen -
9. Re: JBPM - concurrent process execution fails
estaub Jul 16, 2007 7:47 AM (in response to efip10)Koen,
See also http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008324#4008324
It's the same thing, I think. Unfortunately, no JIRA or unit test there, either.
-Ed Staub -
10. Re: JBPM - concurrent process execution fails
efip10 Jul 16, 2007 8:07 AM (in response to efip10)Koen,
Since there's quite a lot of stuff, I'd rather have it sent by email than posted. May I use koen.aers@jboss.com for that?
Thanks -
11. Re: JBPM - concurrent process execution fails
koen.aers Jul 17, 2007 5:58 AM (in response to efip10)Best is to extract a minimum setup that produces the problem and attach that to the JIRA issue (http://jira.jboss.com/jira/browse/JBPM-983).
Regards,
Koen -
12. Re: JBPM - concurrent process execution fails
e120274 Jul 18, 2007 10:59 AM (in response to efip10)I have found a problem with instances of processes. When I start multiple instance of same process, JMSIntegrationService mix the instances inside the Token variable. Two instances started at the same time and in one instance flow did not continue and other instance activity is mixed with current instance process. I have overridden the JmsIntegrationService to get invokes for each activity to handle. Take the token's process instance id and see the problem. Can Jbpm BPEL work with multiple process instances at the same time? It is very important problem I think? Can anyone tried to handle multiple process instances?
Thansk a lot. -
13. Re: JBPM - concurrent process execution fails
kukeltje Jul 18, 2007 12:03 PM (in response to efip10)please use a new topic for this. This topic is on concurrency within one process, not for concurrent instances of a process.
-
14. Re: JBPM - concurrent process execution fails
efip10 Jul 23, 2007 9:44 AM (in response to efip10)As I have tried to build the minimum setup, I come to think that it is not JBPM problem.
Let's put it this way: I create a row in DB, send a JMS message, and create another row. In the end I commit my transaction.
In the meantime my message is processed, and there is a query to the DB for the rows I have created (but not commited yet - or maybe yes?). Obviously, the same race condition would still hold, no JBPM involved.
Maybe using JMS is not a good idea here, and maybe I should use database as a synchronizer (i.e. write a message to my DB and consume it from there by some other thread) rather than JMS. In this case, all the rows will be in DB.