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 Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com