RE: Transaction/Locking with LDAP

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Thanks for that - I do understand resource locking as I worked on the
design and implementation of some very big multi nodal machines for a
mainframe supplier. As said out testing including switching a complete
mainframe off - while it was running as part of a multi processor (node)
system. In this case all dead locked resources and semaphores have to be
recovered, error management performed, roll back dealt with and process
rescheduling performed to restart any failed applications that just
happend to be running on the node in question when it died.

Its not just a question of locking objects in the database and testing
these. Its a question of implementation robustness if the client or
server dies. In addition say I chose to do a transaction that introduces
a referral and I start part of that transaction off on another server
and then the client dies. LDAP I believe can do operations without
Binding - so how does one know about client failure.

My point is, that it is easy to make things work in a LAB, single
instance environment - but when dealing with transactions one has to
test transaction failure and roll back when instigated by extrenal
events (eg power failures) otherwise the concept of a transaction is
pointless.

In your implementation what happens when you lock resources and you
stall the client.

regards alan

> -----Original Message-----
> From:	Satoshi Kikuchi [SMTP:s-kikuti@sdl.hitachi.co.jp]
> Sent:	Friday, June 05, 1998 12:26 PM
> To:	Alan Lloyd
> Cc:	'Ringer, Oded'; 'ietf-ldapext@netscape.com'
> Subject:	Re: Transaction/Locking with LDAP
> 
> 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