Re: [ldapext] Fwd: I-D ACTION:draft-zeilenga-ldap-incr-00.txt

["David Boreham" <david_list@boreham.org>]

> At 08:13 AM 10/21/2004, David Boreham wrote:
> > Is it intended that this feature work with replication ?
>
> Yes.  The client can update the master using Modify-Increment.
> The master can then replicate the DIT change to shadows
> (and these to other shadows).  If the replication protocol
> supports expression of an Modify-Increment change, that can
> be used directly.  Otherwise, the change can be expressed
> as one would a Modify-Replace.
>
> We support two replication protocols in OpenLDAP.  In
> one (a log-based push protocol), the Modify-Increment
> capability of that protocol is used.  In the other (a
> state-based pull protocol), the resulting DIT values
> are transferred.

I see. So in some cases this feature wouldn't work 
(in that it would no longer guarantee atomicity) ?
In the case that you do use an atomic replication propagation
operation, what happens when two 
clients have independently successfully completed
a supposedly atomic increment operation upon two 
different servers ? Is it sufficient that one client
receives the wrong result (at least wrong in that
another client could receive exactly the same value,
talking to another server) ?

Should there be a way for clients to discover if the
feature will work or not ? (or perhaps it shouldn't be
enabled on servers that are participating in replication
mechanisms that renders its effects non-atomic?).



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext