RE: Applicability of LDAP Content Sync to loosely coupled replica sets

Jeff,

An LCUP server, in the case you describe, likely has to require
a full reload.  The problem is that the entry in question may,
after changes are reconciled between the DSAs, be no longer in
the result set and that reconciliation may be done in manner to
which DSA2 never knows the entry was ever in the result set
and, hence, never is able to send the necessary delete message
for the entry.  For example, the entry could have been deleted
from DSA1 shortly the client disconnected from DSA1 and yet
before the entry's creation was replicated to DSA2.

I don't see how LDAP-Sync is any worse off here.

Kurt


At 12:52 PM 6/6/2003, Jeff Parham wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:[email protected]]
>> Sent: Friday, June 06, 2003 10:29 AM
>> To: Jeff Parham
>> Cc: [email protected]
>> Subject: RE: Applicability of LDAP Content Sync to loosely coupled
>replica
>> sets
>> 
>> At 06:36 PM 6/5/2003, Jeff Parham wrote:
>> >> >Is LDAP Content Sync intended to be applicable in this case?
>> >>
>> >> Likely (but I'd have to think about it more).  I note that since
>> >> LDAP Sync supports both updates+present and update+delete
>> >> incremental synchronization mechanisms, if LCUP is applicable
>> >> then likely so is LDAP Sync.
>> >
>> >I'm not sure I agree there.  The key difference between LCUP and LDAP
>> >Content Sync is the ability to assert the "member objects" without
>> >forcing a reload.  The implication is that an incremental sync can
>force
>> >the client to drop previous knowledge, which seems to be the heart of
>> >the problematic example I illustrated.  LCUP doesn't have such a
>> >mechanism; knowledge is lost only on a full reload.
>> 
>> LCUP not only support an incremental sync mechanism (updates+deletes)
>> to drop previous knowledge, servers are to use those mechanism to
>ensure
>> eventual convergence.  If they cannot ensure eventual convergence,
>they
>> are to force a reload.
>> 
>> LDAP Sync provides two incremental sync mechanisms (updates+deletes
>> and update+present), but has the same eventual convergence
>requirements.
>
>By "lost knowledge", I'm referring to knowledge the client did have and
>should have in the future, but now does not.  In the example in
>http://www.imc.org/ietf-ldup/mail-archive/msg01792.html, a client that
>should in the fullness of time have a copy of the new object created on
>DSA1 first gets that object from DSA1, then is forced to drop it after
>performing an LDAP Content Sync against DSA2.  This is what I refer to
>as "lost knowledge", as opposed to the case where synchronization
>indicates to the client that an object that the client synced in the
>past e.g. has moved out of the subtree being synchronized by the client.
>
>How does LDAP Content Sync detect and recover from this lost knowledge
>phenomenon?  If it does so by discouraging or eliminating the mechanism
>that diffs the full set of objects by entryUUID, then LDAP Content Sync
>essentially becomes the same proposal as LCUP.
>
>In short, I would love to see a solution that requires little or no
>history information on the DSA and simultaneously guarantees
>convergence, but I'm having trouble seeing how the differences in LDAP
>Content Sync over LCUP actually enable this in loosely coupled
>deployments.
>
>Thanks,
>-J