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

roschmel do-not-reply at jboss.com
Mon Feb 9 01:16:07 EST 2009


Hi Tom,

thanks for your answer....

Unfortunately - based on my knowledge - only the Thread based JobExecutor handles the exclusive Flag but not the enterprise deployment JobListenerBean. So here would the idea which we are working on would fit in. We could use a JBossCache for managing the exclusive locks for jobs. This would mean, that you also have to do the signals using jobs because it would be the only chance the get them - in a way - synchronized.

Currently when you are using async=true in an enterprise deployment you get the transaction demarcation as you desribed but just imagine following situation:
If I have a process 1 going to node A with async=true and going to node B with async=true (after a fork) then both JMS messages will be commited to the queue to the same time and if you have a fast enought server it will execute both in parallel and you will again get a StaleObject in one of them.

So If you want a lot of transaction demarcation you bring yourself in a situation where you increase the chance of StaleObject and therefore for rollback dramatically.

This is why we did not use async=true for transaction demarcation but we are using BMT and built an ActionHandler that we call SavePoint to commit a running transaction but keeping the Session and the JbpmContext open. This is possible with a little configuration work and one dirty code trick in the ActionHandler to handle the autoSaveInstances.

One other comment:

anonymous wrote : for each potential failure of non transactional resources you need to decide : either the process continues or the process execution rolls back till the last committed point of execution. 

This works well for problems in the external resource - of course you can control this quite well. But if pull the plug right after the non transacted resource did its work sucessfully or if you cannot persist the process itself due to any database failure than you must know in a post mortem view, how long the process ran and where it crashed exactly to have the chance to bring the process back to a "normal" running condition.

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

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



More information about the jboss-dev-forums mailing list