RE: draft-ietf-ldapext-ldapv3-txn-00.txt

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

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Tuesday, April 14, 1998 3:14 PM
> To:	Alan Lloyd
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: draft-ietf-ldapext-ldapv3-txn-00.txt
> 
> Alan Lloyd wrote:
> 
> > It is not clear how:
> > a) That opening a transaction can "reserve" resources that may be
> > deleted or renamed through the course of the transaction. Items in
> the
> >
> > DIB will get modified by a transaction (hence the need for a
> > transaction), but during this process other users may delete or name
> > modify the same resources. Eg the Transaction says modify BILL to
> FRED
> >
> > and then Modify FRED to JIM. At the same time another User has
> deleted
> >
> > BILL or renamed it to JACK.
> >
> > b) That reading an entry within a transaction to update its
> attribute
> > value, when other users can change the value during the process, can
> > be
> > dealt with.
> 
> I believe that these two points are covered in the sectionon
> Isolation.
> Is your comment that that section is unclear, or that
> it's incorrect ?
> 
	The section on Isolation (6.) does not say explicitly that
resources are locked or not. My comments say that is impossible to lock
resources because of threading and persistence searches and what can
stop major deadlocks, but on the other hand resource locking is needed
because of my examples mentioned eg Renames. It seems a dilemma to say
the least.

	I did work on multi nodal mainframe systems where resource
locking was fundamental, but as a fall back we had a deadlock watch dog
arrangement which would knock of "hogging or stalled" applications. Such
features in a directory service could again leave Users in a quandry as
to what state the DIB would be left in if the watchdog fired.

	The point here is that the protocol design is easy for the
"transaction"- but not having a resource locking process/mechanism or
philosophy for determining for dealing with it or what constitutes an
unfriendly transaction that should be dumped - will lead to irregulaties
in the service - to say the least.

	It will be dangerous to say that "during a transaction all
resources will be locked" and that the transaction could contain a
persisten search (for example) which relies on another User or another
transation to trigger the completion of the initial transaction.

	thoughts
	 regards alan
> > The fundamental issues with transactions is not the fact we can
> bound
> > operations within the transaction construct, the major effort is to
> > design mechanisms that lock resources within a system to ensure the
> > transaction is atomic regardless of other users trying to get at
> those
> >
> > resources.
> 
> No argument there, but that's an implementation issue, right ?It's
> been
> observed that directory implementations based on
> sophisticated Relational Database products might find this
> less of an implementation headache than other designs.
> Do you agree ?
> 
> > In a multi threaded machine which is needed for directory services
> > this
> > resource locking could be a problem.
> 
> > The draft does describe that all "transacted" operations occur at
> once
> > -
> > but at once in a real system can be extended because of the client
> > timing issues - ie may be minutes.
> > During this time higher powered clients may have got their
> > modifications
> > completed so that the lower priority transaction then fails.
> 
> Yes, the document presumes locking as the isolation mechanismand
> clients
> may need to wait on locks.
> 
> > Perhaps the use of object oriented design in directory systems as
> > named
> > objects has in fact already defined the smallest form of atomicity.
> > Extending this will cause yet more service consistency issues.
> 
> True, transactions imply larger grain size, which for someaspects of
> implementation complexity and performance is
> a bad thing. Doesn't stop people wanting them though.
> 
> > Server Operation State -Recording
> > Applying transactions to directory operations means that the server
> > must
> > rember state. If Searches are applied to transactions to determine
> > should an update is performed.
> > eg.
> > Search Subtree FOO-Co for Org Persons where title is manager and
> > salary
> > greater than 250k- Then rename entries to FOO-Co, HighPaidManagers,
> > name..
> > What happens if the Search is an LDAP  persistent search within a
> > transaction - waiting for a salary change to occur, this means that
> > resource locking is not practicable.
> 
> Indeed. This problem has been noted. It doesn't, however,seem to deter
> those who want to have transactions in LDAP !
> I believe that the solution to this will likely involve some
> degree of pragmatism.
> 
> > System Design....
> > Although the draft states its for a single server (ie. not
> distributed
> >
> > interconnected servers), the intent IMHO of directory services is to
> > deal with the wider distriuted environment.
> > eg LDAP transactions into an X.500 directory system of
> interconnected
> > servers - will be an issue.
> 
> Recognized as such. Transactions in a distributed system seemto be a
> science project at present. Surely in time the need for
> these will become more clear in time. For now this issue is not
> addressed by the draft.
> 
> > So either this LDAP feature MUST only be applied to a single LDAP
> > server. OR any LDAP User accessing a distributed LDAP server/X.500
> > world
> > will be denied the service. This seems to defeat the purpose of the
> > LDAP
> > standard to be a uniform access method!???
> 
> I wonder if this is indeed true. Perhaps it is. This is a starting
> point.
> 
> > I would like to see that any extension to LDAP eg. results sorting,
> > persistent searches and transaction mode operations is dealt with in
> > terms of their collective use over one server and their use with
> many
> > referred servers is discussed. It seems that in the LDAP client to
> > SINGLE server world, protocol extensions can be easily applied to a
> > point where the LDAP client is built in conjunction with a specific
> > LDAP
> > server. But in the operational world the client (and the User) now
> > needs
> > to be aware of these extensions, whose server they are directed at,
> > and
> > what happens should mid "transaction" referrals are returned and
> what
> > to
> > do if the extensions (eg.transactions) work on one server and not on
> > others. ie we now have a service consistency issue which does make
> > client software complex and no doubt problematic.
> 
> See comment below.
> 
> > My point is as always - its easy to write draft protocol specs
> between
> > a
> > client and a single server and call that a standard. Its not so easy
> > to
> > get compatible services or distributed services working to the point
> > where the user has a seamless and consistent services delivered by N
> > servers from many suppliers . So is it possible, that before we
> write
> > yet more extensions to the LDAP protocol - can we write down under
> > what
> > circumstances a User will use them, how these "transactions are
> > constructed" from a User perspective and how that user knows which
> > server to direct them at and what happens if referrals are received
> > during the transaction.
> 
> I agree. A section covering referrals is needed in the document.
>