Garrett Smith wrote:
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) :-)
It's only a problem for large shared containers that people are
very likely to add to at the same time, so it's a somewhat
specialized problem.
If people don't actually care about ids, you could generate them
randomly.
Another common scheme is to use high-precision times in th names.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
