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