Re: Has anyone got notes & minutes?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:58 AM 8/9/2004, Simon Spero wrote:
>I did have a couple of comments/questions related to asynchronous operations and transactional updates (Section 3/3.1). [remember when this was the ACID working group :)]

I assume you mean ASID, not ACID.  Many of the documents we are
revising were produced by the ASID WG.

In LDAP and X.500, each update operation is processed in isolation
of other update operations.  Each update operation is independent
of other updates.  If the user application, to perform some
task, needs for update operations to be performed in a particular
order, the user application must impose the ordering itself.

Additionally, the DUA cannot reliably assume a directory operation
it issued was successful or not in absence of a response indicating
the outcome.   While a DUA might be able to search the directory
to see if entries it attempted to add exist, there is no guarantee
that presence of said entry is due to its previous update operation
or some other update operation.

>Servers and clients

s/Servers and clients/Messages/

> "generally may be  exchanged between a client and server in any order, provided the client eventually receives a response for every request that requires one. "  Sermersheim, LDAP: The Protocol v25 at 4.

We may need to wordsmith this a bit.  Messages may be generally
be exchanged in any order (regardless of whether the client eventually
receives a response for every request that requires one or not).
If the client violates an protocol or server imposed ordering
requirement, then an appropriate error is generally returned.

>This language is somewhat ambiguous, since it does not specify when we do need to impose at least a partial ordering.

[Protocol] should likely clarify that directory operations are
generally independent of each other.  [Protocol] does say that
modify operations are atomic, but it should say that directory
update service model provides basic ACID properties.  That is,
each update operation is processed as an atomic action, each
must produce a consistent directory state, each is performed
in isolation with other update operations, and state produced
is reasonably durable.

>For example, if two AddRequest messages are sent, the first one creating a parent entry, and the second a child, the second operation will fail if it is processed before the first.  Should this be valid behavior?

The server is free to process the update requests in any order.

>If the client  gets a success response to the second operation before the it has responded to the first, and if the connection is dropped before the response for the first operation is received, MAY the client assume that the first operation also succeeded?

It would be wise to assume such.  The first operation can
fail due to existence of the entry it requested to be added.

>Another example:  if both operations are successfully prepared but not committed, and a search request is received that matches one of the entries,

Becareful.  If the entry addition has not been committed, then
search should not be able see the entry.  If the entry was
committed, then the search may or may not see the entry.

Anyways, lets say the entry was committed and the search sees
this.

>is a server free to send a SearchResult containing that entry before it has send the AddResponse?

Then, yes.

>If the connection is dropped after the SearchResult is sent, but before the AddResponses have been send, SHOULD the server rollback the operations?

No.  A new directory state was established.

>MAY the server rollback the operations?

I would argue, "generally, no".  Once a new directory state was
established and only another user application request should
cause a new directory state to be established.  The fact that a
response for one of the operations which established a state
got lost is, well, too bad, so sad.

Kurt