If two concurrent theads call getAllForUpdate with multiple keys in common (Thread 1 asks for "a" and "b" and Thread 2 asks for "b" and "a" at the same time), is it possible for a dead lock to be formed (where Thread 1 owns a lock on "a" and waits on "b" which is owned by Thread 2 but it is waiting on "a")? More specifically, would v7.0 be affected by this use case?
Pinned topic Can concurrent call to getAllForUpdate cause a deadlock?
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-03-11T13:41:22Z at 2013-03-11T13:41:22Z by StephenW1234
jhanders 1200009V3S265 Posts
Re: Can concurrent call to getAllForUpdate cause a deadlock?2013-03-11T13:22:03ZThis is the accepted answer. This is the accepted answer.You are correct. This is the reason that when doing multiple key operations in an eXtreme Scale transaction that you must order them correctly. This deadlock issue exists in all releases of eXtreme Scale and it is the application developer's responsibility to ensure that if multiple keys are involved in a transaction they are ordered correctly. You can have this same problem without using getForUpdate. It can be seen when updating two keys in opposite orders in a transaction where you don't get any locks except exclusive locks when you commit. Using your example, Thread 1 gets the exclusive lock on "a" and Thread 2 gets the exclusive lock on "b" and then they are waiting for each other on the other lock. This same issue exists in a database world as well. Any time you use multiple keys in a single transaction, this result can happen.
You can read more about how locking works and dealing with deadlocks in the info center here. I referenced the 7.0 info center since you referenced you were using v7.0.
I hope that helps.
StephenW1234 270003QRMF10 Posts
Re: Can concurrent call to getAllForUpdate cause a deadlock?2013-03-11T13:41:22ZThis is the accepted answer. This is the accepted answer.
- jhanders 1200009V3S