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

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

Sorry missed the point below - but more thoughts.
> -----Original Message-----
> 
> > 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 ?
> 
> 
	Yes and No
	Theoretically a group of X.500/LDAP operations can set locks and
be bound in RDB commit services, but that would imply that all the
operations are destined for a DIB held within one Database. This also
implies that the User and the transaction designer is aware of the
implementation/product features and any system partitioning. 

	This direction is against the principles of wider scale
directory services in that named objects can reside anywhere in a
distributed system and that the operation on the object is the highest
and lowest level of atomicity. ie. The transation service implied "can
be implemented" but from an operational perspective it introduces system
vaguaries and constraints that have to be managed. In addition future
system partitioning would invalidate and of the transactions implemented
ie.. add a feature and then define another set of major problems that
the feature operationally wont deal with.


	There is a requirement in X.500 to do "Prune and Graft" whole
subtrees between DSAs. This can only be achieved with Transaction
capability within the (management) client. eg. Read all the entries,
delete the entries, Add the renamed entries. In this case the entries in
transistion do not exist for some instant and if the client fails  in
the process, then recovery steps are needed . This is not impossible to
implement though. 
	If the transaction is re ordered as Read, Add renamed entries
and then Delete, the entries exist twice at some point in time - both
options create recovery problems.

	In LDAP only systems the same issue will arise for moving DIB
lumps between servers and the transaction mechanism - being to one
server only, does not solve anything either.

	So, the transaction system can be a client inspired action, but
on a single server resource locking would be frought with danger if not
impossible. And on a distributed set of servers, a "transaction" can
only be managed by the processing in the client without its semantics
being conveyed to the servers in protocol.

	I would still like to see what a typical directory transaction
is, before the protocol is designed

	regards alan
	PS - one way we can do this in the DXserver (in either X.500 and
LDAP server modes) is to dump the DIB (Database) on line, Put all other
Users into read only mode, update the the DIB in the archive and then
switch it in to the online DSA process (without the other users going
off line) with management control.

	ie. Is the solution to the transaction problem a product
feature/operational process issue. And that no matter what one does with
LDAP or DAP, one can never deal with all the transaction / operational
and scaling issues at the protocol level.