I had written a hierachical lock manager using mysql and once a thread finishes it was unlocking by deleting the locks. The 20 thread perf test was fine but daily some 100-200 of deadlock exceptions would come randomly on some nodes. Now each thread is working in isolation so it doesnt makes sense to get deadlock, the query was like
delete from hie_path_locks where customer_id=? and thread_id= ?
Finally after some hit and try and troubleshooting I found that we had an index on customer_id only and when 10 thread on same workgroup would try to read locks to detect conflicts they would do
select * from hie_path_locks where customer_id=? and thread_id= ?
apparently mysql default isolation of REPEATABLE_READ would take locks on even rows that are read, check http://www.mysqlperformanceblog.com/2012/08/28/differences-between-read-committed-and-repeatable-read-transaction-isolation-levels/
Adding an index on customer_id,thread_id instead of just customer_id solved the random deadlocks.
delete from hie_path_locks where customer_id=? and thread_id= ?
Finally after some hit and try and troubleshooting I found that we had an index on customer_id only and when 10 thread on same workgroup would try to read locks to detect conflicts they would do
select * from hie_path_locks where customer_id=? and thread_id= ?
apparently mysql default isolation of REPEATABLE_READ would take locks on even rows that are read, check http://www.mysqlperformanceblog.com/2012/08/28/differences-between-read-committed-and-repeatable-read-transaction-isolation-levels/
Adding an index on customer_id,thread_id instead of just customer_id solved the random deadlocks.
Comments
Post a Comment