[Zope3-dev] Choose-a-name strategy and write conflicts
Jim Fulton
jim at zope.com
Fri Jun 17 18:43:08 EDT 2005
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:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Zope3-dev
mailing list