Re: Transaction/Locking with LDAP

[Satoshi Kikuchi <s-kikuti@sdl.hitachi.co.jp>]

Alan Lloyd wrote:
> 
>         What happens if the client or server, crashes during the LDAP
> sequence process?

All changes during the transaction are automatically discarded.  The
data store is restored to the state before the transaction.
 
>         Can you please tell me how one can consistently deal with
> transaction recovery when LDAP with a sequence of operations from a
> client can be interleaved with another sequence of operations from
> another client in which read/modify operations can apply and in the
> process things (servers, clients, networks, power, etc may fail) If the
> protocol is not a "one lump" operation and "modify" only.. then LDAP
> servers will end up a mess.
 
In our implementation,

Entries updated during transaction are locked in order to avoid
re-updating and reading unstable information by others.

For example, when the transaction B tries to delete an entry which is
deleted on incomplete transaction A, the server will delay a response to
B due to lock until A terminates.  If A would be committed, B will
receive a result code of noSuchObject.  On the other hand, if A would be
aborted, B will receive a code of success.

Entries searched during transactions are locked for read-modfiy-write.

Sometimes, it would cause the problem for any search operations matched
many entries.  In order to solve this, when a server receives such
operations over threshold, it should discard the transaction and return
a result code of adminLimitExceeded.  See section Client-Server
Interaction in David's document.

>         Say an LDAP transaction sends the first operation in a time 0
> and then the client sleeps abit and then sends in the second operation
> an hour later and then crashes.

By long lifetime, the transaction may be expired.  The client can retry
the sequence from the first operation in new transaction.  See section
Client-Server Interaction.

Regards,
Satoshi