RE: Transaction/Locking with LDAP - additional

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

Some more thoughts

For all those with X.500 directory systems out there which have LDAP
interfaces - this transaction thing means that an LDAP client can start
a multi entry update transaction which updates many objects/entries
which can be in different DSAs in a DSP connected cloud. This means
distributed resource locking is required  in case the client throws in
an errored update or updates so that the "transaction" can be atomic in
nature OR rollback is required
Thats if one is serious about delivering commercial strength systems.

For those out there with LDAP only servers, then LDAP transactions and
resource locking is easier because LDAP servers by definition are easier
because these are not distributed and do not scale. Unless LDP is used
as the "distribution" protocol as well (loop detection?)

So putting this feature in is good for single LDAP servers but costly
and pointless for distributed directy systems which already have a
Replication protocol (DISP).
In LDAP land its like adding another feature to a plane that wont fly.

In my very humble opinion, there is a requirement in many international
corporations to have single service logon. This can ONLY be achieved via
X.500 distributed directory services (with X.509 authentication) that
provide mutual auhentication between the servers/DSAs  - otherwise the
system will not scale. The LDAP only approach is to replicate everything
to everywhere and now protect that replication process with client
process inspired transactions. The failing with this approach is when
one scales up eg:
complex "client managed" transaction issues, massive overheads in
replication, loss of trust and ownership of the information because of
replicated data being passed to others, loss of integrity of replicated
data because of updates and transfer latency and of course lots of
single LDAP servers with gigs of entries. 
 Information Replication should be seen as an "Undesirable" and only
used for backup or where different geographic points of service are
demanded. Replication should never be the mainstay of a directory system
design - one only uses that if distributed direcories are not possible
(eg. LDAP) or distributed performance from the products concerned are
bad.

As said - the core protocol processing architecture and database
algorithms of the DXserver  deal with distribution and distributed
search performance, authentication and access controls first and
foremost. Its that core capability that provides a commercial directory
system.
 
Distribution has to be dealt by LDAP  otherwise it stays as an access
mechanism with the core directory systems as X.500. And if LDAP
development  adds protocol fields that affect distributed directory
operations then they can either be pointlessly applied to a single
server system and ignored on the larger scale distributed directory
systems.

just thoughts alan



> -----Original Message-----
> From:	Ringer, Oded [SMTP:Oded.Ringer@gs.com]
> Sent:	Thursday, June 04, 1998 1:50 AM
> To:	'ietf-ldapext@netscape.com'
> Subject:	Transaction/Locking with LDAP
> 
> Is there any thought to include transaction management in LDAP ?
> -Oded
> 
> 
> Oded Ringer  212-902-7939
> Goldman, Sachs & Co.