I do not see a reason why several instances of an application with embedded jBPM could not run against the same database. Neither was there a real problem running multiple threads for executing jobs (timers/async commands) Or I misunderstand your case completely.
So I'm wondering why you came to that conclusion
thanks for your answer.
The problem in JBPM 3 is that if you execute several instances of an application with embedded JBPM, you will receive optimistic lock exceptions in the timers and on asynchronous commands.
We basically implemented a fix which implements some kind of "reservation" and distributes the timer handling onto the various application instances.
I just found that JBPM 4.0 implements a JobExecutorThreadPool, instantiating 3 executor threads by default.
From this point of view it does not seem to be necessary to start multiple PVMs on the same database instance if the number of executor threads can be increased.
Yup, you are right. Only with timers/asynchronous behaviors can be problem when running in multiple threads, you need to synchronize it using JobExecutor or Quark library.. Running multiple instances of jBPM is probably meant as running it in multiple web/application server threads. And there is only a problem when the same process run for two users, and even not always. It is the same as when one object is edited in two threads. It is matter of configuration of your ORM and database (and there are a lot of options) not a matter of application itself.