Re: [ldapext] nfsv4 vs the ldap consistency model

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Nov 23, 2008, at 4:33 PM, Steven Legg wrote:

> Leif,
>
> Leif Johansson wrote:
> > Kurt Zeilenga wrote:
> > > At present, I'm kind of at b).
> > >
> > > But I don't see how that changes the replication consistency.  In
> > > particular, replication of the data for which the condition depends
> > > upon would still only eventually consistent.
> > It requires that the server does the work of waiting for the update
> > operation to finish on all slaves. If the update failed on one of  
> > the slaves the operation would return an error immediately.
>
> Under the eventually-consistent replication model, the update  
> presumably
> succeeded on the master but has failed to immediately propagate to all
> the shadows (either because a shadow was unavailable, too busy right  
> now,
> or had tried the update and failed). The response should be success  
> with
> an indication that propagation to the shadows was incomplete at this  
> time.
> We assume that one way or another (possibly after administrator
> intervention) the shadows would eventually become consistent with the
> master, but it could take an indefinitely long time. The nsfv4 folks  
> either
> have to be prepared to wait an indefinitely long time for a response  
> or
> else be prepared to handle a relatively immediate response that  
> indicated
> incomplete propagation of the update. It would certainly help to know
> what they are trying to achieve. If a relatively prompt response is
> desired, then the control imposes a requirement on the master to  
> propagate
> the update immediately, despite what its replication schedules might  
> say.
>
> Since a shadow may have its own shadows (i.e., secondary shadows) that
> the master is unaware of, the requirement to not respond until the  
> update
> is fully propagated would have to be applied by a shadow to its
> interactions with the secondary shadows. However, the protocol used by
> the master to communicate with the shadow and/or the protocol used  
> by the
> shadow to communicate with the secondary shadows might not provide the
> means to indicate the requirement (X.500 DISP, for example).

Or it could be a cache copy.

The control, I think, needs to be the read, not the write.

-- Kurt
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext