Re: LDAP extensions for subtrees.

[Bruce Greenblatt <bgreenblatt@dtasi.com>]

At 10:29 AM 6/23/99 -0400, Mark Smith wrote:
>If other operations are not allowed to interfere with the "end result"
>of a subtree operation, the burden on server implementors will be quite
>high.  Isolation is an expensive thing to achieve when we there are
>millions of entries in one subtree.  For example, what should happen if
>a different LDAP client tries to delete an entry that is part of a
>subtree that is in the process of being copied?  Thousands of examples
>like this can be dreamed up without much trouble.
>
>I'd really like to see a precise definition of the required LDAP server
>behavior included in the next revision of this draft.  I for one am
>still very "fuzzy" on what is required of server implementations.

Mark,

Thanks for the feedback.  In my mind, there are tradeoffs in the
implementation here.  If other operations are allowed to interfere with the
end result, of a subtree operation, it will be difficult to replay the
operations from a transaction log.  What do you think?  I think that it
ought to be possible to save a snapshot of the LDAP database, store off a
serialized sequence of operations, and then replay them, and come up with
the same end result time after time.

Bruce

>
>I feel strongly that all LDAP subtree operation proposals should remain
>at draft or experimental status until we have some implementation
>experience.
>
>-- 
>Mark Smith
>Directory Architect / Sun-Netscape Alliance
>My words are my own, not my employer's.  Got LDAP?
>
>
> Bruce Greenblatt wrote:
>> 
>> At 11:00 AM 6/22/99 -0600, Jim Sermersheim wrote:
>> >So these operations are atomic in the sense that a single operation is
>> >issued, as opposed to atomic in the sense that the data specified
>> >(subtree or filtered subtree) is to be treated as an atomic unit,
>> >correct?
>> 
>> That's pretty much all that I mean.  In the sense that you are trying to
>> "serialize" the LDAP operations, I would think that you'd consiser one of
>> these operations as a single entity so that other operations couldn't
>> interfere with the end result.  The primary point of this draft is that:
>> 
>> - these are common requirements for LDAP clients
>> - it is too cumbersome and time consuming to issue the commands
individually
>> 
>> For example, my copy subtree routine using the existing LDAP API takes
>> about 13 minutes to copy a subtree of 4000 objects.  In this scenario, I'm
>> running Netscape DS 3.01 on a 300 Mhz PII, and the client and server are on
>> the same machine.  I can imagine that the DS could figure out a more
>> efficient way to carry this out internally than making the LDAP client
>> retrieve every object in the subtree, synthesize a new copy of the object,
>> and then transmit the new object back to the DS.
>> 
>> Bruce
>> 
>> >
>> >Maybe the word atomic carries more meaning than was intended and could
>> >be substituted with a less loaded word.
>> >
>> >>>> Bruce Greenblatt <bgreenblatt@dtasi.com> 6/22/99 9:56:04 AM >>>
>> >At 08:19 AM 6/22/99 -0700, David Boreham wrote:
>> >>
>> >>
>> >>Bruce Greenblatt wrote:
>> >>
>> >>> Thanks for the feedback.  This intention of the draft is that the
>> >SOS
>> >>> operations are to have the same end result as if the LDAP client
>> >had
>> >>> submitted a stream of standard LDAP operations.  So, you can't
>> >delete
>> >>
>> >>Isn't this at odds with the requirement that the
>> >>tree operation be atomic ?
>> >
>> >I don't think so.  The operation is just atomic from the client
>> >perspective.  It is up to the server to make sure that the result is
>> >correct.
>> >
>> >>A client submitting a stream of deletes can
>> >>see one fail half way through the sequence.
>> >>
>> >>
>> >
>> >Only if the client submits each operation synchronously, and waits for
>> >the
>> >result.  Since the operation can fail for any number of reasons, not
>> >just
>> >access control.  If the client wants to delete an entire container,
>> >why
>> >should it have to search the subtree, retrieve all of the entries, and
>> >then
>> >delete them individually?  This make very little logical sense to me.
>> >
>> >Bruce
>> >
>> >>
>> >
>> >
>> >
>
>
>