Re: [ldapext] nfsv4 vs the ldap consistency model

[Howard Chu <hyc@highlandsun.com>]

Kurt Zeilenga wrote:
> On Nov 23, 2008, at 4:33 PM, Steven Legg wrote:
> > 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.

OK, if we're going to actually discuss this seriously... This is going about 
the problem the completely wrong way. It is impractical in most cases and 
impossible in many cases for a particular master to determine when an update 
has reached every shadow copy.

Also, for the most part, answering the question "has the update reached every 
copy" is unnecessary. The only question that matters is, "have all relevant 
updates reached the server I'm currently talking to?"

The dontUseCopy control is too restrictive in its functionality. What you 
really want is a "AreYouUpToDate?" control. And *that* is something you can 
actually implement, because any shadow will know who to ask to get the answer 
to that question. And, you can implement it without forcing all of the servers 
in a replication setup to pay the cost of distributed locks and two-phase commit.

I would suggest an "AreYouUpToDate?" control with a timestamp or CSN argument. 
The question being asked would be "do you have content equal to or newer than 
the specified CSN?" i.e., "have you already received this update?" The value 
to supply in the CSN argument can be obtained using a PostRead control on a 
previous update operation.

Alternatively, the control could specify an interval of acceptable time 
difference (e.g. 5 seconds) and the contacted server would poll any masters it 
knows about to see if it is sync'd to within the specified interval. (And if 
the contacted server is the master in a single-master setup, it can obviously 
just answer directly.)

Additionally the control could force the current operation to wait until the 
specified sync interval constraint is fulfilled.

The main point being, the query that started this thread, and distributed 
transactions in general, force every server (and consequently, every client) 
to wait before progress can be made. That's foolish, because the progress of a 
particular update isn't important to every server and every client; only a few 
agents in the system know about and care about a given update. Only the agents 
that actually care about a particular operation should pay the cost of 
overseeing the progress of the operation.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext