RE: Transaction/Locking with LDAP

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

> -----Original Message-----
> From:	Satoshi Kikuchi [SMTP:s-kikuti@sdl.hitachi.co.jp]
> Sent:	Thursday, June 04, 1998 2:59 PM
> To:	Alan Lloyd
> Cc:	'Ringer, Oded'; 'ietf-ldapext@netscape.com'
> Subject:	Re: Transaction/Locking with LDAP
> 
> Alan Lloyd wrote:
> > 
> > I hope not.
> > 
> > Otherwise we will need resource locking and transaction recovery
> > mechanisms in LDAP and that is somewhat difficult in distributed
> > directory systems . It will need this - otherwise the transaction ID
> > will just be a cosmetic protocol field.
> > 
> > Isnt it odd that one can add a few bytes to a protocol field to say
> > "transaction ID" and put that on a sheet of paper in 10 minutes.
> But to
> > make that work in a commercial tested large scale object oriented
> > distributed name based transaction system that has true rolback
> > integrity it will take years and millions of dollars...
> > 
> > regards alan
> > 
> 
> We have discussed directory services with some customers and were made
> to recognize realities that some cases, especially mission critical
> systems such as EC, couldn't adopt the directory service without
> transactions.  Their requirements concentrate for consistency among
> multiple updates to the single server.
	What happens if the client or server, crashes during the LDAP
sequence process? 

	Yes - the principles of object oriented design actually dictate
the atomicity levels of information items and as X.500 is object
oriented it atomicity is implied in the design - we deal with this
atomicity in the implementation through our RDB back end with commitment
services and the ability to switch/rolback the database. WE are fully
aware of EC and military dependency of directory systems hence the
quality, integrity and performance  of our products and our presence in
those markets.


	X.500 applies DISP as a "transaction protocol" for multiple
updates - its supposed to be atomic ie DISP extends the atomicity from
the object level to the "group update object level".
	This of course is managed with replication agreements and DOP.

	It strikes me that X.500 is already doing what LDAP is now
trying to do, but X.500 has also introduced a management framework
around this transaction process in the terms of replication agreements.
LDAP transactions will also have to be managed in the same way.
	X.500 uses diffrent protocols for different reasons and
atomicity levels - Access -DAP, Distribution and Chaining DSP,
Replication/Update Transactions - DISP and Management DOP.



> We thought that our draft could satisfy most requirements even if it
> does not address transactions which span more than one server.  It is
> complicated to implement the distributed transaction such as TP
> monitor
> though adding the protocol for that isn't so difficult.
> 
> It is important to solve technical problems positively and meet users'
> expectancy.
	We do. And our systems scale.
	It is also important to make sure that the features added to a
standard are valid and applied consistently and robustly. It is also
important to recognise that this problem has already been solved in the
right way and more completely, written into an international standard,
implemented and deployed.

	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.

	One could say in the LDAP spec "that if the control "Transaction
ID" is set then Searches/Reads are not permitted. In the event of these
operations being found, then all operations relating to the transaction
will fail and be terminated"...However, this will not stop other clients
deleting and renaming entries which are in the path of the updating
sequence of operations - unless one locks the server when a transaction
is encountered

	ie.  what does one do about resource locking. ie Client A sends
update Q, update P, delete R, Add X, Rename S-T and Rename U-V and
during all this without transaction mode on, Client C, D, E, F come in
and remove the entry's optional attributes, rename S to X read R, etc. 
	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. 

	Transaction processes MUST have an atomic protocol element that
can be received, vetted, processed and confirmed in one instant in the
server.



> Current draft is lacking in a few definitions such as locking,
> referral.  It will be revised up soon.
> 
	Well - all I can do then is wish good luck to the implementors.

	regards alan

> Regards,
> Satoshi