I reproduced this error with the unit test that I pushed to this repo:
Inside you will see these two test methods:
public void testOneSingleRun(): this one works without problems.
public void testMultiThreadedRun(): this one works if the number of threads is 5 or less, but it fails if there are more threads (try starting with 6).
The error is like this:
Caused by: org.h2.jdbc.JdbcSQLException: Deadlock detected. The current transaction was rolled back. Details: "
Session #2 (user: SA) is waiting to lock PUBLIC.ACT_RU_TASK while locking PUBLIC.ACT_HI_TASKINST (exclusive), PUBLIC.ACT_HI_ACTINST (exclusive).
Session #1 (user: SA) is waiting to lock PUBLIC.ACT_HI_TASKINST while locking PUBLIC.ACT_RU_TASK (exclusive)."; SQL statement:
Why is it so, if I’m creating a different processInstance for every thread?
Also, I kept the process definition as simple as possible:
My test just does this:
start process instance with variables
update variables three times
complete the first task
This is close to what our real application does, we are updating processIntance variables from a frontend wizard before completing the corresponding user task.
Can somebody help me to understand the reason why and to avoid this error?
Thanks in advance,
H2 uses table level locks by default, so that’s why you get deadlock issues when you do anything in parallel. Enable multi-version concurrency control for row-level exclusive locks: http://www.h2database.com/html/advanced.html#mvcc. And lastly: don’t use h2 for production.
I verified that this does not happen if I run my unit test against mysql… This test was the closest I got to reproduce and isolate the original error that we get in our application, which was this one and I was not able to solve:
Do you see something suspicious in our datasource that could be causing this error?