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