0 Replies Latest reply: Mar 15, 2013 4:53 PM by 997249 RSS

    Handling Deadlocks and Nested Transactions

    997249
      Hi,

      I'm new to BerkeleyDB and have a rather specific question:

      When a deadlock exception is raised, and you're in a nested transaction environment, which one of the nested transaction are you supposed to abort and repeat?

      You could repeat the innermost, but if the innermost inherited locks from its parent and those locks caused the deadlock it must result in a deadlock again, possibly indefinitely.

      But always repeating the outermost transaction (root transaction) seems wasteful, is there no way to tell which one of the transactions on your "transaction stack" acquired the lock which is on conflict with another transaction?