Not really, I see the workflow as a container for managing a long running transaction which may may have different users or different operations acting upon it within its life cycle.
The issue is not one of cache but one where at any one wait state the Web application needs to maintain the task, use/set variables on that task and then signal it to move on. While it is in one wait state it is not a single page operation that is getting/setting the values. I really do not want to have to copy the values out of the task into another container and then copy them back in when I want to save the task. The task is the container that maintains state so why should I not be able to hold on to it across contexts. When the default persistence is used, a task or process instance within jBPM seems to be closely coupled to a transaction which is not typical for a workflow engine. It is not a criticism just an observation and one that the developer needs to be aware of and design their application to handle. Of course I could write my own persistence but then I would lose all of the hard work the JBPM team has put in. The behavior I was expecting was that if I used one of the "ForUpdate" methods then the instance was closely coupled to a transaction. If I simply loaded it then I was responsible for saving it but could do so across any context. I am just trying to fully understand the operations that effect design decisions within my applications when I use jBPM. I still plan on using it as I am a big supporter of anything from JBoss. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4021074#4021074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4021074 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
