2 Replies Latest reply on May 6, 2010 10:39 AM by Maurice de Chateau

    jBPM- Transaction isolation level

    Alexander Sem Newbie

      Dear Experts,

      I use jBPM schema database with separate custom scheme/tables database. Custom aplication do queries to jBPM scheme.

      What is best/optimum transaction isolation level for  jBPM datasource or have to be equal to custom aplication datasource?



        • 1. Re: jBPM- Transaction isolation level
          HuiSheng Xu Master

          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.

          • 2. Re: jBPM- Transaction isolation level
            Maurice de Chateau Newbie

            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.




            1 of 1 people found this helpful