FW: RE: Architecure Draft [Transactions]

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From:	Alan Lloyd 
> Sent:	Monday, 24 August 1998 11:23
> To:	'Ed Reed'
> Subject:	RE: RE: Architecure Draft [Transactions]
> 
> Ed. the DISP protocol is implied to be a transaction eg a ROSE based
> thing. Therefore a DSA that implements DISP either does it or does not
> do it. Nothing in between - just internal operation based magic!
> 
> In reality though it takes some doing. And good DB commit services
> help. This is where all other non DB directories take a hit (we think
> :-))
> 
> hope this helps 
> regards alan
> 
> -----Original Message-----
> From:	Ed Reed [SMTP:ED#032#REED@xxxxxxxxxx]
> Sent:	Saturday, 22 August 1998 1:15
> To:	Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx
> Subject:	Re: RE: Architecure Draft [Transactions]
> 
> Alan - I guess I'm not familiar with the version of DISP which
> propagates
> transactions in-tact, or the object-level (or is it attribute-level?)
> locking
> primatives which extend DAP to make them safe.  Do you have a pointer?
> 
> We haven't solved or addressed them here, because we're not aware
> of what the system must do to support them.  The requirements document
> for transactions will no doubt provide us insight.
> 
> As we said, we've not gone out of our way to obstruct replication of
> transactions, but neither have we attempted to specify how to do them.
> There may very well need to be a "different" mechanism to support
> distribution of transactions through a distributed directory
> environment,
> and we have attempted, with the ReplicationMechanismOID on the
> replicaAgreement object, to leave room for future innovation.
> 
> Ed
> 
> -------------------
> Ed Reed, Technologist
> Novell, Inc.
> +1 801 861 3320
> 
> >>> Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx> 08/20/1998 19:23:02
> >>>
> John - having just returned from a long US/europe trip. and seeing all
> the LDAP extensions for:
> Persistent searches, Transactions, triggers, signed operations (which
> should be signed audit records) and initiating replication processes.
> I
> am concerned that if these extensions applied together by a naughty
> client what would an ldap server do. ie if transcation IDs lock
> resource, then how does one replicate in, what happens to a ldap
> server
> with persistent searches and triggers if one zaps in 200,k entries in
> replication processes.
> 
> In addition most of the extensions being added do not work well in a
> distributed model. ie to put a transaction state, a trigger state and
> a
> persistent search state accross a distributed system where you do not
> know how many servers actually are involved with such a search
> operation
> - all hell will break loose..
> 
> But I suppose this is really upto the LDAP server (non X.500 types)
> implementors to sort out. All I can do is wish them good luck. - and
> the
> customers that use them.
> regards alan
> 
> 
> 
> > -----Original Message-----
> > From:	John Merrells [SMTP:merrells@xxxxxxxxxxxx] 
> > Sent:	Monday, 10 August 1998 9:05
> > To:	Alan Lloyd
> > Cc:	'LDUP '
> > Subject:	Re: Architecure Draft [Transactions]
> > 
> > 
> > 
> > Alan Lloyd wrote:
> > 
> > >   c) How transactions will be replicated. However, the
> architecture
> > >     should not knowingly prevent or impede them, given the Working
> > >     Group's incomplete understanding of the issues at this time.
> > >
> > > Alan - this one must be defined - otherwise LDUP is not a
> protocol.
> > 
> > I agree that once LDAP transactions have been defined they must
> > be faithfully replicated by our replication protocol.  However, one
> of
> > our objectives is to avoid tying ourselves to any other work items.
> > So, we're attempting to keep transactions in mind, rather than
> > demanding that they be defined before we more forward.
> > 
> > John