RE: WG Last Call on the LDAPv3 Directory Replication I-D

["Ed Reed" <eer@xxxxxxxxxxxxx>]

Ahh - the crux of the matter...



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

>>> "Albert Langer" <Albert.Langer@xxxxxxxxxxxxxxxxxxxxx> 02/17/01 04:59PM >>>
[snip]
My view is that the critically important requirement that applications
depend on
is simply that a change can be reliably made to exactly the entry you
thought you
were changing and not result in some mixture of updates combined with
unknown
concurrent changes by some other application.

[eer]

My view is exactly, precisely, and PROFOUNDLY the oposite - that it is critically
important that changes to different attributes made at the "same time" to
the same entry at two different master replicas MUST interleave and both
be preserved.  

That, in fact, the expected (by reasonable application users sharing
information for multiple applications using LDUP replication to facilitate locally
improved performance and availability of directory content for those applications)
behavior is atomic at the attribute level (if, indeed, not at the attribute-value level) 
for each attribute being changed.  This is, of course, the administration 
application of the directory as a distributed nameservice for which vendors
like Microsoft, Novell, and Lotus use directories.

That there is no practical way to utter the request "change
attribute A to have value "alpha" if and only if attribute B has exactly the
value "beta"" using LDAP and X.500 absent locking mechanisms (theoretical
discussions to the contrary being considerably outside the scope of "normal
and customary" usage to be expected of application developers).

That distributed databases of whatever nature which support such things
do so outside the scope of what can reasonably considered "LDAP".  And
that LDUP is not appropriate for preserving such locking semantics, and
is not intended to be.

That when such locking semantics are defined for LDAP, that LDUP may
then consider how or indeed if they can be reliably replicated via some
use of LDUP or some modification of LDUP, but that until such semantics
are defined that it is foolish to attempt to preserve them in LDUP.

That the simple perspective that because it is possible (by standing
on your head and waving a chicken about with precisely the correct
flapping pattern of your legs) to achieve some sort of "test and set"
behavior against a single server, that the ability to continue to 
provide the behavior to a group of distributed, replicated servers
operating without benefit of distributed memory of any sort (and
thus, operating locally autonomously - which IS the desired behavior
to provide continued access and availability to the data that ARE
present for local applications in the face of network outages) should
somehow be a show-stopper represents a fundamental disagreement
over what is desired from a "loose consistency multi-master replication
scheme for directories supporting LDAP".

That there are LOTS of alternative approaches to providing shared
application profile information, ranging from ACAP (which I
would characterize as a network accessible associative
memory service) to a distributed shared memory system intended
to provide cluster-level disk sector semaphores (with or without
write-down mandatory access control prohibitions).  These are
things LDAP and LDUP are not suitable to support.

That if needed to move things forward, to encourage multi-vendor
inter-replication of LDAP directory content, I would gladly advise
developers who attempt to create their own locking or test-and-set
operations to be sure that, as Albert has correctly described "a change 
can be reliably made to exactly the entry you thought you
were changing and not result in some mixture of updates combined with
unknown concurrent changes by some other application" that they
do so at their own peril when operating against directories supporting
LDUP.

Look, folks - this all would have been easy to provide for fully
atomic operations against multiple-master replicas...just add XA
semantics to LDAP for enforcement among all master (updateable) 
replicas with full two-phase commit support for each required
atomic operation.  Phase one, all masters would verify that
they had no pending operations which are in conflict with
the proposed changes and that they're blocking any new such
requests until the commit or rollback command is received.  Phase
two, commit or rollback after all updateable replicas reply "ready".

But that's NOT WHAT WE SET OUT TO DO.  THAT'S NOT WHAT
ANY OF US WANTED TO IMPOSE.  THAT'S NOT WHY WE'RE
USING LDAP.  

STOP TRYING TO MOVE US THERE!

Albert - as far as I can tell, even Microsoft has moved towards
interleaving attribute changes, away from the entry-level sequence
number scheme that CODA and ADSv1 used.  No, LDUP won't
do that.  I personally don't think it SHOULD do that.  We may
agree to disagree on that point.

Best regards,
Ed