On Fri, May 21, 2010 at 6:40 PM, Vincent Pelletier <vinc...@nexedi.com> wrote: > Le vendredi 21 mai 2010 15:52:05, Jim Fulton a écrit : >> packing and conflict resolution on the server > > BTW, I'm not sure why it happens this way. Is it to save the cost of > transferring 1 or 2 revisions of the object over network when resolving ?
Conflict resolution is done on the client because that's the way it was done originally and hasn't changed. (It may be that conflict resolution was implemented before ZEO. I don't remember off hand.) Conflict resolution should, and eventually will be done on the client. The data needed by the client has a good chance of already being there. > In NEO we chose to do that resolution on client side, Good choice. > but it should cause > fewer latency problem (if it's the reason behind this choice) as we hold > object-level locks, rather than storage-level locks: we don't delay unrelated > transactions. I'm not sure what you mean by object level locks. I've been planning to add something similar to object-level locks during the commit process, so multiple transactions can be doing commit-related activity at once. Independent of that, It should be possible to check for conflicts and deal with them on the client during the first phase of 2-phase commit. Note that ZEO doesn't get the storage lock until the end of the first phase. > And for packing, the "second phase" (tree walk to prune unreachable objects) > is indeed a problem. In my work on pack (not integrated yet because of a shift > in priorities) I implemented it on client side too, but this is motivated by > the fact that storage nodes don't have a complete view of the database because > of data partitioning for load balancing. This phase will probably be disabled > by default before integration. Note that you're really talking about garbage collection, not packing. ZODB with zc.zodbdgc, already lets you separate packing and garbage collection. You could argue that zc.zodbdgc is a specialized client. The danger of this approach is that the client needs a lot of data, which is why zc.zodbdgc is designed to work with replicas. As with NEO, zc.zodbdgc was motivated by multiple databases where a single database doesn't have enough information to perform garbage collection. Jim -- Jim Fulton _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
