[ZODB-Dev] help enabling conflict resolution

[Jeremy Hylton]

On Sun, 2004-02-29 at 18:13, John Belmonte wrote:
> > I'm not sure how to debug this or trace the problem because I get 
> > confused with ZEO in the equation.  Only the ZEO server has an actual 
> > FileStorage instance, so does that mean the conflict resolution code 
> > runs only on the server?  The ClientStorage doesn't have to inherit from 
> > ConflictResolvingStorage, right?
> 
> I think I located the problem, which was that the ZEO server didn't have 
> my app modules in the Python path.  It seems like the only time it 
> actually uses the app code is for conflict resolution, which is why I 
> didn't notice the problem earlier.  Sorry for the noise.

Yes.  Conflict resolution runs on the storage, because it runs while the
storage is locked by a single transaction; we don't want the storage to
block while data is sent back and forth between the client and server. 
(Although an alternate design where the server aborts the transaction
and the client retries after running only conflict resolution seems
possible, that still involves transfering data from client to server
twice.)

One problem with this approach and with the use of a method to perform
conflict resolution is that app code gets loaded in the server.  If your
application code does any initialization as a side-effect of being
imported, that initialization will happen inside the ZEO server.  That's
known to be a problem with Zope/CMF.

We're planning to change conflict resolution to use explicitly
registered functions.  There's no need to use methods, since conflict
resolution operates on an object's serialized state rather than the
object itself.  The registration would allow the application to be much
more careful about what gets loaded in the server.

Jeremy