Topic
  • 2 replies
  • Latest Post - ‏2013-03-11T13:41:22Z by StephenW1234
StephenW1234
StephenW1234
10 Posts

Pinned topic Can concurrent call to getAllForUpdate cause a deadlock?

‏2013-03-11T12:35:54Z |
Hi,

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?

Regards.
Updated on 2013-03-11T13:41:22Z at 2013-03-11T13:41:22Z by StephenW1234
  • jhanders
    jhanders
    260 Posts

    Re: Can concurrent call to getAllForUpdate cause a deadlock?

    ‏2013-03-11T13:22:03Z  
    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.

    Jared Anderson
  • StephenW1234
    StephenW1234
    10 Posts

    Re: Can concurrent call to getAllForUpdate cause a deadlock?

    ‏2013-03-11T13:41:22Z  
    • jhanders
    • ‏2013-03-11T13:22:03Z
    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.

    Jared Anderson
    Thank you for the reply. I suspected this would be the case. I just wanted to check there was no magic under the hood (given that the keys could be spread across multiple partitions, it would probably need some potent magic to remain scalable).