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

[dboreham@netscape.com (David Boreham)]

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 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.