The transactions I'm referring to are not jBPM transactions per se, they are transactions for the client application I am writing that happen to operate on jBPM objects. For example:
Request 1: User retreives a list of Tasks Request 2: User clicks on a task and views information for that task Request 3: User clicks on the "Action" tab to enter a comment and choose a transition Request 4: User enters a comment, chooses a transaction, and clicks "Finish" The task is loaded in request 1 and cached as a part of a list in a session-scoped managed bean. The user clicks on the task, which sets the "selectedTask" property of the session-scoped managed bean equal to the task instance that was clicked on. The user then proceeds to navigate a serious of read-only views that operate on "selectedTask" task instance (#{sessionBean.selectedTask.name}, for example). Finally, in Request 4, the user choosed to do something with the task, but since there are many associated entities loaded in previous requests I get a LazyInitializationException. I gather based on your response that the preferred behavior would be to store the task instance ID in the session bean and load a fresh copy on each request, making each request a short transaction (most read-only with some being updates). That would certainly work, but it's not very efficient, especially if associations have to be lazily initialized on every request (task instance variables, for instance). What I've ended up doing is using the cached TaskInstance for all of my read-only operations, and calling Session.refresh() on the TaskInstance before performing updates, effectively making the update transactions short transaction (read-modify-commit in a single request). A cascading lock operation would be nice, so at the end I could simply do version checks (or use LockMode.NONE and rely on optimistic locking). Session.refresh() is a little dangerous because it will read the state from the database without a version check and may result in some of the user's changes being lost without notification. Session.update() isn't an option because there are many-to-one associations that would have to cascade, and it is not reasonable to expect update operations to cascade in those cases. - Jesse View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931363#3931363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3931363 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user