[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] nfsv4 vs the ldap consistency model
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).
Regards,
Steven
If what they are after is transactional consistency, there may be
existing LDAP implementations which provide this. I recall something
be presented in this area at LDAPcon.
Transactional consistency would solve the problem but I think what
they need is somewhat less than transactional consistency. Not sure
if it is less enough to warrant a standard extension.
Cheers Leif
------------------------------------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext