Subject: no-copy control requirement

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 09 Apr 2001 00:29:03 -0700

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: "John McGarvey" <[email-masked]>
Date: Mon, 9 Apr 2001 10:30:02 -0400

Kurt,

I suggested such a mechanism about 2 months back, because such a mechanism
could ensure atomicity of changes for one or several entries.  This
suggestion was pretty much ignored by the list.  Albert replied that this
would create a single point of failure, and that to require the client to
know where the master is for some replication context is inconsistent with
a globally scalable distributed environment.

I believe, however, that such a mechanism is needed to give atomicity of
changes.  Some on this mailing list have suggested that we solve the
atomicity problem with error notification.  Error notification is
necessary, but it is an anemic solution, which would likely require
frequent administrative intervention.

At that time, I suggested that there be a "master master" for each
replication context.  This does create a single point of failure, and it is
not transparent to the client.  So, here's an alternative approach.
Perhaps there should be an "atomicity lock" for each replication context,
which could pass from server to server.  If a server that holds the lock
goes down, another server could reclaim the lock by majority vote of the
rest of the DSAs for that replication context -- eliminating the single
point of failure.  Also, if the client passes controls indicating the need
for a group of changes to be applied atomically, the server with which it
is communicating could either request the atomicity lock, or pass a
referral to the current holder of the lock.  (An atomic change to a
collection of entries which are spread over several replication contexts is
more difficult.  A single server may have to claim several locks, and there
would have to be a mechanism to prevent deadlock conditions.)

-- John McGarvey

"Kurt D. Zeilenga" <[email-masked]>@mail.imc.org on 04/09/2001 03:29:03
AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  no-copy control requirement

Kurt