the create.jbpm.configuration in the jboss subproject will install the standard environment jbpm-console.war in the deploy directory for now.
the enterprise/ear subproject takes the jbpm-console.war for standard environment and applies the necessary updates to have it work in an enterprise environment. also the other enterprise beans will be included in that .ear build target.
The way I see it, no transaction should span more than a single request or form submission on the webapp. In read/modify/write cases we should (if we have not already) adopt an optimistic locking style of strategy, where we trigger an error on form submit if the relevant server state has changed between the request of the form and the submission of the same form.
That said, I don't see why we can do whatever we want with transations, at least with respect to the web application.
My apologies if I'm duplicating what you've already said.
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. Of course this may or may not be possible - I'm still not familiar enough with the API to know for sure. Working on it though!
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.
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 ?