(Commit-)LockManager is not fair

[d-maurer]

The ZEO server associates a commit lock with each of its storages, managed by a LockManager.

The lock manager uses a dict to remember which connections are waiting for the commit lock. When the lock is released, the lock manager gives each of them the chance to obtain the lock - at most one will succeed, the remaining are put back into the waiting dict. The success chance mostly depends on the order in which connections are asked whether they can use the lock. The current implementation used Python's "dict" order. This is not a fair order: a connection at the first place has a persistently higher change to get the lock than following connections (because if they come back, the dict order will remain the same).
Theoretically, it is possible that a pair of high volume writers starve the other writers.

Fairness is only important if there is significant contention, in this particular case, significant transaction frequency by multiple clients. Because the ZODB does not perform well in such situations, they are likely rare. Then, fairness would not be a big issue.