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

Jeff,

>Sufficient replicated history information could rectify that without
>requiring a reload.  Or if the DSA wasn't sure if the client had
>previously synced the object, it could send the deletion anyway.  Or it
>might choose to force a reload.  LCUP leaves this design decision in the
>hands of implementers.

When full reload is chosen, LCUP has the same problem.
The client sees the entry added to DSA1 when it synced with DSA1,
but will not see the entry after it syncs with DSA2 via full reload.

If it is not allowed to lose forward progress in consistency,
a possible approach would be to not remove entries previously
not seen from a DSA when a client syncs with the DSA.
For example, the client does not delete the newly added entry in DSA1 
when it syncs with DSA2, because it never received the entry from DSA2.

This can be used both for LDAP-Sync and for LCUP in the full reload mode.

- Jong





"Jeff Parham" <[email protected]>
Sent by: [email protected]
06/07/2003 12:07 PM

 
        To:     "Kurt D. Zeilenga" <[email protected]>
        cc:     <[email protected]>
        Subject:        RE: Applicability of LDAP Content Sync to loosely coupled    replica sets




Thanks for your responses, Kurt -- I think this is a very valuable
thread.

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email protected]]
> Sent: Saturday, June 07, 2003 4:35 AM
> To: Jeff Parham
> Cc: [email protected]
> Subject: 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.

Sufficient replicated history information could rectify that without
requiring a reload.  Or if the DSA wasn't sure if the client had
previously synced the object, it could send the deletion anyway.  Or it
might choose to force a reload.  LCUP leaves this design decision in the
hands of implementers.

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

If LDAP Sync employs the set-diff by entryUUID method, it always
requires a reload in this case.  How does the DSA know to force a
reload?  Apparently any time the client's last sync was from a different
source DSA from the replica set.  That would seem to make LDAP Sync (or
an LCUP implementation that always requires reloads in such a case)
unsuitable for loosely coupled environments in which high availability
is achieved through replication -- environments in which a client may
frequently choose alternate DSAs to sync from.

If LDAP Sync does not employ the set-diff by entryUUID method, then
you're right: LDAP Sync is no worse than LCUP, but it's also no better
-- they're essentially the same.

What I'm getting at here is the ultimate viability of set-diff by
entryUUID.  If it's not viable in this common scenario -- and
unfortunately I don't believe it is (I very much liked its promise of
"no history required") -- then there's really only one proposal for
client synchronization on the table.

Thanks,
-J