Hi Alexander,

Commonly, jBPM 4 used optimistic lock to prevent concurrent thread modify the same record in database.  When there were splited execution need to be merged, e.g. in the JoinActivity, jBPM 4 used LockMode.UPGRADE to lock the parent execution. It is means that it will send a SQL likes 'select * from T for update' to lock a record in database and prevent other thread modify this line.

  So, if you want to do some integration work, you should consider about using optimistic lock.

Hi Alexander,

You're not mentioning which version of jBPM you're using, but in the user guide for version 3.2.x (http://docs.jboss.com/jbpm/v3.2/userguide/html/persistence.html#isolationlevelofthejdbcconnection) you can read the following:

"Make sure that the database isolation level that you configure for  your        JDBC connection is at least READ_COMMITTED.

Almost all features run OK even with READ_UNCOMMITTED  (isolation level 0       and the only isolation level supported by HSQLDB).  But race  conditions might occur in the        job executor and with synchronizing multiple tokens."

So that's quite clear in itself. But if you want a little more background, you can read this JIRA issue (JBPM-983), in which Tom Baeyens explains about the underlying reasoning for this persistence aspect.

Regards,

Maurice