Normally pessimistic locking on the ProcessInstance is just fine. In general transactions in jbpm are not very long running. If you do have long running transactions e.g. in synchronous action executions, you could opt for optimistic locking, but then you would have to adapt the jBPM database schema to include the versioning.
thanks for the reply.
Normally locking on ProcessInstance would be ok. What I'm doing is hooking up an imaging server to a legacy workflow system to a host to another host to whatever the business people in a large international bank may come up with.
All of these calls spend more time in the remote systems then actually doing anything.
If its on the top of your head: is locking on Tokens enough? If you don't know, I'll check it out next week anyway and post the result. It's just that I'm not a hibernate crack, so it will take a while.
Well this depends. If signalling a token on one path of execution does not modify process variables or other state that is used by other, parallel paths of executions, this should be ok. If not, locking the processInstance is the only option, but you could go for optimistic locks in this case...