This was observed during multimaster testing: Two high priority transactions T1 and T2. The T1 which was ordered first faced a lock conflict due to asymmetric locking and had to check the state of T2. However, T2 had already called provider::commit_order_enter() without releasing the mutex. Because T2 could not proceed as it was ordered after T1 which was trying to acquire T2 mutex, deadlock occurred.
This was observed during multimaster testing: Two high priority transactions T1 and T2. The T1 which was ordered first faced a lock conflict due to asymmetric locking and had to check the state of T2. However, T2 had already called
provider::commit_order_enter()without releasing the mutex. Because T2 could not proceed as it was ordered after T1 which was trying to acquire T2 mutex, deadlock occurred.