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

Like LDAP, this extension to LDAP is designed to be used
in directory systems which act in accordance with X.500.
If one is using this extension in a system which doesn't
adhere single-master aspects of the X.500 data model,
lots of more than this operation will lead to application
problems.  I discuss these problems in
draft-zeilenga-ldup-harmful (currently expired, I will
refresh shortly).

For instance, applications which incrementing values using
Modify-Delete+Add would suffer from the lack of ACID
properties in the multi-master system.  Likewise, applications
which used Modify-Increment would suffer from the lack
of ACID properties in the multi-master systems.

In LDAP, clients may presume server is acting in accordance
with the X.500 data model.  If the server is unable or
unwilling to do that, then it should not provide service.
Clients which do desire an alternative service model
should explicit request that model (through a request
control or other mechanism).  And, as far as how to perform
this operation (or any other operation) within an
alternative service model, I will leave that those who
desire to specify alternative service models.

Kurt

At 09:44 AM 10/21/2004, David Boreham wrote:
>>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

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