"david.lloyd(a)jboss.com" wrote : The way I see it, no transaction should span more than a single request or form submission on the webapp. | correct. i see typically 2 possible transactions in one request: 1) the command transaction. if a user performs a UI operation that results in an update to jbpm this is done first in a separate transaction. of course, not all requests have a command transaction since many links are just navigation. 2) view rendering transaction. this is the transaction that is used to read all the data from the database to render the next view. by splitting these transactions, the time that the command/update transaction is kept open is minimal. it is that command/update transaction that may acquire locks (optimistic or pessimistic). in no case, transactions should span multiple requests. one way of implementing the above transaction strategy is by making use of the JSF phase listener. the update command will be in the invoke application phase. so before that phase begins, a JbpmContext can be created and injected in a request-scoped bean. (e.g. the JbpmBean). Then after the invoke applications phase, that JbpmContext could be closed and a new one could be created for the rendering phase. After the rendering phase, also that JbpmContext could be closed. Then it is a matter of binding the JbpmContext lifetime to the transaction in the standard or enterprise environment respectively. thoughts ? "david.lloyd(a)jboss.com" wrote : | Also, I don't really like the idea of keeping a heavyweight state on the web application side either. Ideally the web application would be purely stateless. | I agree. id's if jBPM objects should be in the rendered client page. So that the next request is always stateless. Does that correspond with what you say ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968020#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...