There are two approaches for concurrent task assignment in particular and database access
in general: pessimistic locking and optimistic control.
In the first approach, you lock the task instance
(jbpmContext.getSession().lock(taskInstance, LockMode.UPGRADE) before you update it. The
first transaction that attempts this will get the lock and proceed. Other transactions
will have to wait until the first transaction releases the lock. This approach has the
following drawbacks:
While a transaction waits for the lock to be released, the thread executing it will be
stalled and your application will appear unresponsive to its clients
After acquiring the lock, you have to check whether the taskInstance has already been
assigned
Locking is supported differently between databases. Some do not support specific lock
modes and cause your app to behave in unexpected ways
Optimistic control does not rely on database-provided mechanisms but in checks made by the
application. When a conflict is detected, one of those StaleStateExceptions is thrown.
There is no reason to consider this an unaesthetic programming style, because it is a
well-known practice. What you gain here, full application responsiveness and predictable
behavior across databases, outweighs the inconvenience of catching the exception.
By the way, you shouldn't catch all Exceptions, but only JbpmPersistenceExceptions.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4013154#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...