transactions, commands and packaging

[tom.baeyens]

i'm creating 2 packages:

* a plain POJO .war file targetted to be deployed on e.g. tomcat. the idea is that most of the libs will be inside of the web application, including the configurations for a non-enterprise environment.

* a .ear enterprise application that has 3 components and the jbpm libs inside (referenced by the Class-Path entry in the manifests). The components are jbpm-console.war, cmdlistener.jar (MDB) and cmdservice.jar (SLSB). The configurations are packaged as a jar library that all components can 'see' and contains all settings for a enterprise environment. So this package will contain a different version of the .war, one in which the libraries are placed differently and with different configuration files.

As for transactions, both will work in the same pattern: one update transaction for user commands. one read-only transaction to render the new view. This is done with a JSF phase listener. In the standard environment, the transactions will be delegated to hibernate. In the enterprise environment, the transactions will be manipulated with the UserTransaction JTA API.

The command patter that we considered between the web app and the jbpm command service doesn't make much sense. Especially since there is an overlap in transaction managmement there. The JSF approach will call the backing beans once and a while for each item that needs to be rendered. If all of these result in a transaction, it would be a completely different (slower) model then the one we envision with max two transactions.

Feel free to ask more info or challenge these insights. These ideas have not yet had the time to stabilize...

[tom.baeyens]

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.

[dmlloyd]

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!

[tom.baeyens]

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 ?

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 ?