[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: Transaction/Locking with LDAP

To: "'Sanjay.Jain@software.com'" <Sanjay.Jain@software.com>
Subject: RE: Transaction/Locking with LDAP
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Date: Fri, 5 Jun 1998 09:50:13 +1000
Cc: "'Erik Andersen'" <ERA@FL.DK>, "'ldapext'" <ietf-ldapext@netscape.com>
Delivered-to: ldapext-archive@critical-angle.com
Resent-date: Thu, 4 Jun 1998 16:55:42 -0700 (PDT)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"rGF_F2.0.xB1.yFpTr"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com
One of the features we have is a  DISP client which is script driven in
our DSA so that a script can be built that sucks via DAP/DSP/LDAP
Searches (and filters) any entries from a directory system and then
builds a DISP PDU for a "transaction" onto another DSA. (I suppose one
can do this for the same DSA).

I fundamentally believe that one can easily stick " a transaction ID" on
a sequence of random protocol operations - but when it comes to
implementation robustness - that is known not the thing to do.

As said LDAP with transactions means that its spec must say that
Searches are illegal if transaction controls are set.

It also means that implementations (both client and server) are robust
and not open to interrrupts/other operations  during the "transaction".

For those who want to go down this path - what the real test is get a
LDAP server and some clients - set some transactions up - say a dozen or
so LDAP update/delete/rename operations in each transaction. Run the
system flat out and randomly pull the power plug on the server and
clients and see what happens re Client recovery, Server recovery and DIB
integrity. If the system does not survive - why have transactions.

Perhaps all those LDAP server customers will do this as part of the
acceptance and payment tests for the products.
We have tested our system this way (pulling the plug) and because it  is
RDB based, it works and is back on line within 10s of seconds.
Transactions in LDAP are good if they are implemented in a Robust way -
which some how I doubt that can be the case. But that is open to others.


However, X.500, RDB s with online switching, commitment services and
alternate DSAs and DSP route redundancy and multimaster - via DB tools
replication and the use of DISP, etc  some how has our vote for system
robustness.

its no good putting such a theoretical feature in a protocol spec  if
the implementation of it makes it a mockery.

regards alan
> -----Original Message----- 
> From:	Sanjay.Jain@software.com [SMTP:Sanjay.Jain@software.com]
> Sent:	Friday, June 05, 1998 9:04 AM
> To:	Alan Lloyd
> Cc:	'Erik Andersen'; 'ldapext'
> Subject:	Re: Transaction/Locking with LDAP
> 
> What is the solution for directory applications which don't need
> distributed
> and partioned
> directory but need transactions ?  I think lot of such directory
> applications are coming up.
> From that point of view support for transactions in LDAP is a big
> plus.
> 
> My $.02.
> 
> sanjay
> 
> Alan Lloyd wrote:
> 
> > Eric - I had similar thoughts transactions but its the job of ISO
> CCR to
> > do commitment which I think DTP used. So X.500 supported by CCR is
> the
> > theoretical solution.
> > However, implementing distributed systems with transaction rollbacks
> is
> > tall order - thats to get the products  to industry strength and
> > commercial grade. EG. a DAP stack is about 130kb but a DSA is 100 -
> 200
> > times that. CCR as just a protocol set - may be 6-12 man months
> > development. CCR in a fully robust distributed system  (ie. 20 DSAs
> +)
> > is 100 times the effort. Just think of all the investment that has
> gone
> > into X.500 and LDAP development and still there are a lot of shakey
> > implementations re distribution, performance, cashing issues, etc.
> So
> > distributed CCR on X.500  has to be in my book a $5-10m dollar
> > development. And that quote is from someone who quotes development
> costs
> > for directory developments.
> >
> > X.500 as an object paradigm is robust. DISP as a
> transaction/replication
> > paradigm is robust. The use of commercial RDB back ends with
> commitment
> > services and the ability to switch archive the DIB ensures these
> > paradigms are robustly implemented.
> >
> > regards alan
> > PS there are always religious wars in standards groups (IETF, ISO
> and
> > ITU) and in fact these wars also happen in religious groups. I think
> > these wars are:
> > a) part of what us humans do.
> > b) applied when engineering debates are not well supported eg.  "to
> > avoid the overheads and complexity of OSI and DAP"  = religion...
> as
> > these are 130kb. Half of which is produced automatically by an ASN.1
> > compiler. ie. Manual coding effort for OSI and DAP is 65kb of code.
> > Manual coding effort for LDAP is 200+kb of code for less functions.
> >
> > > -----Original Message-----
> > > From: Erik Andersen [SMTP:ERA@FL.DK]
> > > Sent: Friday, June 05, 1998 1:16 AM
> > > To:   'ldapext'
> > > Subject:      RE: Transaction/Locking with LDAP
> > >
> > > From the very beginning I believed, i.e. back in 1983-84 I
> believed
> > > that
> > > X.500 in stead of ROSE should use Distributed Transaction
> Processing
> > > (DTP)
> > > which was at that time a very well developed protocol based on IBM
> LU
> > > 6.2
> > > and had all the features of two phase commitment and roll backs.
> It
> > > would
> > > therefore not require years, but some added implementation cost,
> but
> > > probably not millions of dollars. However, as usual, I was alone.
> The
> > > chairman of the ISO Directory group was totally against it.
> "Directory
> > > is
> > > stateless and shall stay that way". We also had our religious wars
> > > within
> > > ISO.
> > >
> > > Erik Andersen, Consultant, Direct Tel. (+45) 3945 0736, Mobile:
> (+45)
> > > 2097
> > > 1490
> > >  E-mail: era@fl.dk
> > >
> > > FISCHER & LORENZ A/S
> > > Tuborg Parkvej 10, DK-2900 Hellerup, Copenhagen, Denmark
> > > Tel. (+45) 3945 0700, Fax (+45) 3945 0777, E-mail: fl@fl.dk,
> Internet:
> > > http://www.fl.dk
> > >
> > > CEN/ISSS Directory Workshop chairman, Internet:
> > > http://www.cenorm.be/isss/workshop/dir/welcome.htm
> > >
> > > > -----Original Message-----
> > > > From:       Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> > > > Sent:       4. juni 1998 01:14
> > > > To: ERA@FL.DK
> > > > Subject:    RE: Transaction/Locking with LDAP
> > > >
> > > > 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
> > > >
> > > > > -----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.
> 
>
Prev by Date: Re: Transaction/Locking with LDAP
Next by Date: Re: Transaction/Locking with LDAP
Index(es):
- Chronological
- Thread