Hash: SHA1

Jim Fulton wrote:
> 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.

The current thread ID would also give you another source of variation.

- --
Tres Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to