Re: "atomicity" in LDUP

[alison.b.payne@xxxxxxxxxxxxxxxx]

Sorry - I'm making up my own definitions of atomicity.    Your statement
below - "The net behavior...etc" is true.  There are "historical" reasons
for me using this, but you don't want to hear them.

I agree that the atomicity statement needs some qualification, also
mentioned below.   Needs to be tackled for the high level spec, and may in
the ideas of serialisability and the constraints which are maintained etc.

>As far as I can tell, the intent is that client operation atomicity is
>preserved.  I've asked about this in various conversations, and pretty
>universally gotten the reply that the intended level of atomicity is
>exactly that of the original LDAP client operations (I'm not sure what the
>story is about other directory access protocols, nor even exactly which
>LDAP versions are intended).  Also, section 3.2(c) of
>draft-merrells-ldup-model-01.txt seems to be trying to say this.

>You've made statements that seem to be contrary, and given an example in
>the privately-circulated URP02.doc; that example suggests we're using the
>term "atomic" a bit differently.  In that example, the client operation O1
>is a MODIFY that changes two attributes' values.  At some DSA, O1's
>primitives arrive after the later-stamped primitives of a second MODIFY O2
>that changes one of the same attributes (e.g., by p-remove-attribute plus
>p-add-attribute-value).  You note that the now superfluous O1 primitive
can
>be discarded , saying "This example shows that the atomicity of the modify
>operation [O1 in my nomenclature] is (quite sensibly) broken if the sense
>of this operation is to be maintained".  I would say that this example
does
>not show any atomicity being broken, only that later-stamped primitives
>overwrite earlier-stamped ones, regardless of order of arrival at a
>particular DSA.  The net behavior of a DSA is *as if* it had atomically
>executed each client operation (that it has effectively received
primitives
>from) in some order.

>draft-merrells-ldup-model-01.txt makes a similar statement in section
>3.2(c), stating an objective is "To preserve the atomicity of LDAP
>operations.  Updates to an entry, from multiple sources, will be combined
>such that the resultant entry is equivalent to a serial execution of the
<operations."

>All such statements actually need a bit of qualification to account for
the
>fact that the "execution" of operations has cases that don't arise in the
>single-master situation.