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 Fulton
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to