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
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
