• Vincent Pelletier's avatar
    Resolve deadlocks detected by storage nodes. · 7fccafeb
    Vincent Pelletier authored
    Also reverts r2533: even if it's true that TIDs have no meaning at that level,
    they are a handy way to prioritise a transaction over another, to break lock
    cycles (aka deadlocks). This is the "detection" part of the change.
    When a storage reports a deadlock, client must store all already-stored
    objects again with "unlock" flag set.
    Upon receiving those store requests, storage must release locks held by
    transaction on those objects, and requeue the store request. If client didn't
    hold any lock (initial store was still in queue), drop the second store
    request.
    This doesn't solve possible deadlocks if ZODB-level sends us objects in a
    different order (ex: client 1 sending [OID1, OID2] & client 2 sending
    [OID2, OID1]).
    There is one important change to r2533's revert, which queues older
    transactions and notifies deadlock for younger ones. The original code did it
    the other way around, and it looks unfair to old transactions (they will keep
    being delayed by younger ones, and will just get older and older).
    
    git-svn-id: https://svn.erp5.org/repos/neo/trunk@2596 71dcc9de-d417-0410-9af5-da40c76e7ee4
    7fccafeb
handler.py 19 KB