Subject: Re: no-copy control requirement

From: "Ed Reed" <[email-masked]>
Date: Mon, 09 Apr 2001 08:09:06 -0600

And, this would require either

1) reinstatement of the "primary" replica designation, as the "owner"
of all data in the replication area (not the same as the server to
which all data modifications are made, but a "soft" designation for
use by applications, like replica topology management, to use
by common agreement as the single server to use so that such a
"high confidence" or "no copy" bit can be made to make sense), or

2) carry sufficient information on each attribute value so that the
server where that data was originally entered into the DIT can be
identified (the CSN replica id may suffice), so that the client (or
chaining or referring server) can individually contact each of the
servers at which various values of attributes for the entry was
entered and verify that the values read at the copy are still
the values of record at the originating server.

Of course, in a multi master environment, there's no guarantee
that #2 above will actually contact a server where an update
has occurred that has not yet propagated to either the DSA
handling the no-copy request from the client (presuming it is
either chaining or that it is trying hard to provide useful
referral information to the client), or indeed to the DSA where
the original value was entered.  

Using the approach in #1, it is possible for applications with
single-master dependencies to algorithmically select a single
master of all the master replicas (by looking at the replica types)
to which to direct their modification operations, without unduely
hindering other applications that dont' require such relatively
high assurance consistency.  But it does not give the client
nor any server the omniscience required to locate as yet un-
replicated changes among the replicas of the DIT.  

I don't know of other approaches to providing this non-LDAP
control, but I agree its a necessary thing to define.  I had
thought it something to be defined as part of the distributed
operations model of the directory, instead of the LDUP
itself.

It's also interesting to consider how the whole subject of
referrals and how they're to be generated gathers the information
to give to the client who wants to constrain itself to talking
to data where "copy is not sufficient" constraints are in place.  
Another argument, in my view, of using information in the DIT
that includes replica type knowlege, as the source of things
like subordinate references (so references generated
for clients who have asserted the "no copy" control will be
correctly directed to the appropriate replica of the subordinate
name space).

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <[email-masked]> 04/09/01 01:29AM >>>
X.500 replication model provide a mechanism for clients
to state the operation should not be preformed on a 
copy of the entry.  This is useful when the client
needs to ensure it is operating upon the master DSA
instead of a shadow DSA.  There likely should be some
requirement to support this feature in LDUP.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 10 Apr 2001 14:29:00 +1000

Ed,

In X.500 single master replication an entry is either a master (modifiable)
copy or a shadow (read-only) copy. For every shadow entry there is a
corresponding master entry, transient inconsistency notwithstanding.
In our current multimaster architecture an entry is either a shadow copy,
a co-mastered copy or a single-mastered copy. There is either one
single-mastered copy of an entry within the replica group or two or more
co-mastered copies. If we use a no-copy *bit* then we have to decide
whether it means don't use shadow entries or don't use shadow or
co-mastered entries. If it means the latter then an operation should be
failed if no-copy is requested but the entry is co-mastered.

If one master replica is nominated as some sort of primary then we have
four possible entry copy states: shadow, co-mastered, primary-co-mastered
or single-mastered. An entry can have both co-mastered copies and a
primary-co-mastered copy within the replica group.

A two-valued control isn't enough. We would want clients to be able to
request one of the four following treatments through a control.

1) Use any kind of copy. This case doesn't apply for updates.

2) Don't use shadow copies (use any mastered copy). This case should be
the default when the control is absent. I'm inclined to map the X.500
dontUseCopy service control to this case as well. This control setting
won't cause an operation to fail.

3) Don't use shadow or co-mastered copies (use primary-co-mastered or
single-mastered copies). The operation should be failed if there is
no primary-co-mastered or single-mastered copy.

4) Don't use shadow or co-mastered or primary-co-mastered copies
(use only single-mastered copies). The operation should be failed
if there is no single-mastered copy.

If the control is expressive enough then we don't need to *mandate* the
existence of a primary master replica. Clients decide if it matters to
them whether a primary master replica is actually deployed.

For good measure we can also add a fifth case to the control:

5) Guarantee strong consistency. If the entry is single-mastered then
strong consistency is already assured, but if the entry is co-mastered
the control implies the client is requesting that a distributed update
be invoked - something like the locking solution John McGarvey is
talking about, or the strong consistency solution I sketched out previously
on the mailing list.

Regards,
Steven