[jbpm-dev] [Design of JBoss jBPM] - Re: Concurrency in jBPM4

[roschmel]

Hi,

let my try to explain my thoughts in short:

1) A lot of external system cannot be rolled back (WebService Calls, Legacy Systems...).
2) To make it worse, there are also a lot of system where a retry causes major issues (think about a Bank Transfer - doing it twice may not be good choice)

So in an ideal world you would exactly know where the process execution has crashed. This would mean committing every little step - but this is not really cool stuff.....

So its first about knowing where the process have crashed - therefore you need logging information - just another topic I am currently discussing in the user forum.

And its about minimizing the chance, that a jBPM Transaction is getting rolled back. It is espacially about not considering a rollback as "a normal path of execution" - a rollback is for really bad things happended and not per design. So I think SOSE and retrying as a designed path of execution is simply wrong.

What I would expect:
If I have a process 1 waiting in state-A and waiting in state-B for the callback from an external system and both of them sending me the signal at the same time, I expect to have them executed just one after the other and I do not expect getting exception and letting the engine doing things twice.

We are currently working on a pessimistic locking feature for this situation. But there are two major issues with it:
1) You have to find out what the shared resource is based on the command you get (and its most of the time the parents- parents- ... processinstance)
2) We are doing it in the CommandService EJB and because its a synchronous method call we have to block the thread until we get the look



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207712#4207712

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207712