anonymous wrote : For instance, in JBPM3, you could have a rollback that would obliterate some or all of the activity on other "tines" of a fork. Everything is in sync, but the behavior is probably unexpected. One way to mitigate the "roll back all 30 branches of execution" is to place async "save" points in your process--whether by jBPM's own async feature, or your own JMS functionality. This way, the process would persist itself before continuing. If you had a roll back on one branch, you'd just roll back to the save point for that branch. This way, the process has a 'plan' for managing transaction scope. Since we should all be catching reasonably expected exceptions, a failure to commit should be an extraordinary event in which there is no certainty of what went wrong. In such a case, the only safe response is to roll back the entire transaction to some manageable point--preferably where you started. Sure, some JMS integration messages may have gone out the door, but they're all tagged with a business key/id that would allow them to be resent without causing trouble (right?) So in my line of thinking, I would definitely want everything rolled back and in sync. Unfortunately, many of our use cases aren't limited to two transactions. As the signalled process moves back and forth gathering or updating data in the domain, the XA can wrap several transactions. For instance 1) Domain updates data and signals process 2) Process execution sets status at some point on domain objects (e.g. inProgress) 3) Process execution continues 4) Process reads domain objects for decision making, forking, etc. 5) Process updates status on domain objects (e.g. inService) 6) XA finally commits These issues became large enough that we no longer start processes directly from the domain application--all initial signalling of new process instances is now done via JMS. (The domain creates and prepares the process instance, but uses JMS to signal out of the Start state.) But this only addresses the first hand-off between transactions; if, in the same execution, the process itself updates the domain then later tries to read the same domain table row (for example, from two different ActionHandlers), the we have the deadlock again because we're utilizing different DB connections. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204186#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...