[Zope3-dev] Choose-a-name strategy and write conflicts

[Garrett Smith]

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.

This would apply to the issue tracker, wouldn't it? 

> 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.

Unfortunately, we need to keep the ids small because they show up in the
URLs.

I ended up implementing a secondary ZODB that serves next-in-sequence
values per container (ala an RDB generator). This turned out to be more
straight forward that I thought it would be.

 -- Garrett