"estaub" wrote : I meant that it should be easy for someone to understand where the transaction edges are, without digging into the implementation of each delegation class. So part of this is a designer UI issue, but the engine has to behave in a way that the designer UI can predict. Someone modifying the process shouldn't need to exhaustively study the behavior of every component already in the process in order to understand where it will rollback to if an error occurs. [On the other hand, it's very reasonable to expect someone adding a node to understand its transaction semantics.] | I don't see a good way on how transactions could be visualized in the graphical process designer. The default behaviour of jBPM is simple. As long as the process itself is executing, this is done synchrnously (in the same thread) and hence in the same transaction. This is good in case the processing inbetween the wait states is minimal. For most workflows that include human tasks and other wait states, it usually is a perfect default. For some kind of batch processes, people will probably want the opposite default. Namely that the transaction is committed after each activity and automatically the next activity should start in a new transaction. I'm thinking of supporting this in jPDL 4 by allowing the user to specify/overwrite the default async continuation behaviour on the process level. "estaub" wrote : is it valid to have an Activity that is not an ExternalActivity, yet waits for an external event? I hope not | You are correct. It is not. Wait states *have* to implement external activity. If an activity can ever get into a wait state, then an external activity has to be implemented. the naming comes from the fact that the driver for propagating the execution is external to the process during a wait state. Let me know if you think there is something left which is not rigorous. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135686#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...