Re: LDAP extensions for subtrees.

[Bruce Greenblatt <bgreenblatt@dtasi.com>]

Rob,

There are certainly issues here.  I think that there are logical answers to
your questions.  First I'll observe that the existing LDAP/DAP operations
that modify the DIT must rely on some sort of locking mechanism in the
underlying data repository.  For example, in a database layout that I
helped design for an X.500 repository some years, the information from
entries from organizational type objects (Os, OUs, OPersons, etc.) was
spread across at least a dozen SQL tables.  Even a simple Add operation
required the behavior that you describe.  The operations that I propose are
no different.  My only assumptions here are:

- these are common operational requirements for many LDAP applications
- these are easier for the server to perform atomically than for the
  client to implement as a long series of operations
- It is easier for the LDAP server to implement a single copy subtree
operations
  than it is for it to implement arbitrary transactional behavior when
forthcoming
  operations are not known.  Thus a copy subtree operation will be more
efficient than
  scads of add operations surounded by a Begin-End transaction block.  The
same observations
  are true for the other operations that I propose.

Thus, there is benefit here for both the client and the server.

If you view the operations that I propose (the SOS operations) as atomic,
then if an operation that modifies the target subtree comes in to the LDAP
server during the time that it is implementing the SOS operation, then the
end result should be whatever would happen as a result of serializing the
operations.  As long as the SOS operations are viewed as atomic there is no
more need to lock the subtree, than there is during a modifyDN operation.
Referrals are an interesting issue as well, but there is likely similar
solution here as well.  The worst thing that will happen is that a client
will get a referral, and during the time that the client is chasing the
referral, the DIT will have been changed by an SOS operation, and the
referral is now completely bogus.  Of course, this can happen now as well.

Bruce

At 07:32 PM 6/20/99 -0700, Rob Weltman wrote:
>  Bruce Greenblatt wrote: At 09:50 AM 6/20/99 -0700, Rob Weltman wrote: 
>    There is some need for subtree operations besides moddn, at 
>>least subtree deletion, but the draft proposal doesn't handle 
>>transactionality, locking, and distribution (referrals) - which I believe 
>>are the hardest things related to subtree operations. Rob Yes, but these
>operations are all atomic, which bypasses the need for 
>transactional capabilities at the LDAP level...
>  What happens if there is a modification (deletion, addition) in the
>subtree during the operation? Is there an implicit assumption that the
>subtree is locked from the start of the operation until the end? The client
>may not need to worry about transactionality, but I think the server does
>(unless it already implements subtree operations atomically). Depending on
>the server, that may or may not be a very difficult thing to do. And there
>is the question of how referrals are handled during the subtree operation
>(assuming the managaDSAIT control is not included with the request). Rob 
>