RE: [Zope3-dev] Choose-a-name strategy and write conflicts
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Choose-a-name strategy and write conflicts
Jim Fulton wrote at 2005-6-17 18:43 -0400: ... If people don't actually care about ids, you could generate them randomly. And the ZCatalog uses a scheme (choose random starting point in a thread, then allocate sequentially until a conflict occurs), which is supposed to work very well with BTrees conflict resolution. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Choose-a-name strategy and write conflicts
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 Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Choose-a-name strategy and write conflicts
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-1714http://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
