The use of INameChooser is useful for picking names that don't conflict
across serial transactions. But this approach is problematic when two or
more transactions are tying to add objects to a container at the same
time. Because 'choose name' relies on its isolated version of a
container, multiple threads are destined to choose the same name
(assuming non-random algorithm), resulting in a write conflict.

In some cases a write conflict is a normal and healthy thing to get,
particularly if you let users edit the same object at the same time
without care. But adding new objects to a container when the names are
chosen by the system should not cause this problem. E.g. if the objects
use unique keys, the BTree conflict resolution should gracefully handle
the concurrent adds.

The only solution that occurs to me is to use an alternate persistence
mechanism (e.g. a file or database) for 'next name' sequences and
control access to it via a thread lock.

Is there a way to do this in the ZODB without the use of some external
file-locking/update mechanism?

Does this problem even make sense to people, or have I lapsed into
garbled nonsense (again) :-)

 -- Garrett
Zope3-dev mailing list

Reply via email to