When you are running in a clustered environment, e.g. with jBPM embedded in a clustered stateless session bean, our advice is to use pessimistic locking on the database level.
Thank you for the advice, but can you please explain why should we use pessimistic locking. What is the disadvantage of using optimistic locking.
You *can* use optimistic locking, but in that case you will have to alter the jbpm tables in order for them to include a version number field. This is not included at present. The rationale is that you should lock your affected table rows if you don't want two concurrent branches of the same process instance to update their state/tokens at the same time. Pessimistic locking is just fine to do that. The performance will in 99% of the cases not be harmed badly, as the number of concurrent execution paths in process instances is generally not high, so the chance of an update collision is likely to be low.
I'm interrested by the subject. I want use JBPM in a clustered environnement behind a stateless session bean facade.
I don't understand how to use pessimistic locking (how to turn on pessimistic locking) in JBPM.
I read hibernate docs and we could explicit set the lockMode with a call to :
Is there a parameter to set in Hibernate/jbpm configurations files, on the application server, the database (oracle 10, transaction level isolation ???), or must I modify the JBPM source in some specifcs cases ?
Is there something I missed or I don't understood ?
I have the same question.
How does one "turn on" pessemistic locking?
The Hibernate docs you found specify exactly the way how you should do it.
hibernateSession = jbpmSession.getSession; jbpmObject = lookupJbpmObjectYouWantToWorkOn(...); hibernateSession.lock(jbpmObject , LockMode.UPGRADE);
The jbpmObject is any variable, token, etc. for which update collisions should be impossible.
Forgive me for possibly sounding like a dunce on this topic.
I had thought that I would run the starter-kit in JBoss, but use another process to signal tasks. This way the timer/scheduler runs in Jboss, but I can expose a REST style interface for task instance management (something which I haven't figured out how to do in pure java yet because my EJB knowledge is currently low).
So the "other process" could do the locking as you describe above. But what about the jbpm deployment in Jboss? It won't be doing this locking, right?
It seems that pessemistic locking is an all-or-nothing requirement. And so if I have an "embedded deployment", I cannot also use the starter-kit deployment in Jboss because that code isn't doing locking.
Do I have a valid concern?
The locks are always obtained by the client processes that do the signal. The jBPM engine runs always in the client thread that signals the process to transition to another state.
The jBPM engine runs always in the client thread that signals the process to transition to another state.
Right, so in my embedded process, jBPM engine will do it's work in the thread that has already called the lock.
But I have configured the jBPM deployment in JBoss to use the same hsqldb that my external embedded process is using.
And that JBoss instance of jBPM is in it's own JVM process... that code will not be doing any locking, right?
I am using the stock starter-kit /jbpm-server deployment to run the timer/scheduler and the built-in process and task management/monitoring code web interface. Those threads (the timer, and the servlet for the web interface) running JBoss are not using pessemistic locking, right?
This is my point, while my custom embedded code can explicitely lock the hibernated object, the standard jBPM timer/scheduler and web interface in the jboss server deployment doesn't do this locking.
Isn't that going to be a problem?