directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: A control for enabling/disabling dynamic schema check ?
Date Tue, 12 Jun 2007 09:05:17 GMT
Actually come to think of it the use of a cascade req. control along with
the logic into the server close to where the data resides might be the best
approach.  It certainly will be faster and safer:

(1) the data is local so access and writes are faster
(2) the schema subsystem manages it so the code is isolated where it belongs
(3) the failure of the network connection between the client and the server
     not result in leaving the server in an inconsistent state with respect
to the schema
(4) the client does not have to deal with latency and multiple operations so
     over all the performance will be faster
(5) the client complexity decreases
(6) when transactions are enabled with better atomicity and isolation then
     can be enabled and there is no inconsistent state for the schema
     we can still make sure the schema is not inconsistent while performing
     operations in the server - just more work)

Some drawbacks:

(1) the server's schema subsystem must have code added to it to handle this
(2) more complexity in the schema subsystem but not as much as in the client

     since there are structures already present in the schema subsystem for
     these kinds of operations/checks
(3) time :)


On 6/12/07, Alex Karasulu <> wrote:
> On 6/12/07, Pierre-Arnaud Marcelot <> wrote:
> >
> > Hi Alex,
> >
> > I think you need to make the server only writable by the current session
> > > using the
> > > control to prevent other clients from making inconsistent updates.
> >
> >
> >  Exactly. That's why I wanted to use a control. To do a "per request"
> > disabling feature. Schema check will always be activated unless the control
> > is present in the request.
> >
> Actually I don't think you can use a control and I want to clarify the
> required
> behavior. First off you need to use an extended request to frame multiple
> add requests.  It's not so much a control since you have to perform
> multiple
> adds while having the schema checking disabled.  See if any schema check
> were to occur before the set of operations are completed the schema
> subsystem
> will be in an inconsistent state.  Hence no write operations can occur  by
> any
> other client session during that frame.  Here's what it would look like:
> 1). Send Disable Schema Checks Extended Request
> 2). Receive Extended Response (yes or no)
>      - if yes we can begin and all other client sessions cannot do
> add/modify/modifyDN ops
>      - if no then we cannot begin: scheme checking has not been disabled
> and process ends
> 3). Sequence of N Add Request/Response Pairs w/ Schema Disabled
> 4). Send Enable Schema Checks Extended Request
> 5). Receive Extended Response
> So we cannot use a control for this because a series of add requests are
> required.  But
> and extended operation is ideal.  This btw is how LDAP transactions and
> other bulk
> operation framing mechanisms in some draft specifications work.
> The danger of this is that the schema could be inconsistent and you don't
> have rollback
> capabilities since we don't have transactions.  I wish we had transaction
> support since
> this is an ideal use case for it.
> Also it's a good idea to add parameters into the schema service and the
> > > configuration
> > > that could control this.
> > >
> > > Overall it's a good idea to be able to control the server in this
> > > fashion however it does
> > > not come without risk.
> >
> >
> > Yes, I'm really aware of that. That's why a complete schema integrity
> > checker will be built in the Dynamic Schema Editor, to prevent putting in
> > the server a wrong schema configuration that could leave it in a unstable
> > state.
> >
> I see but would it not just be easier to construct a dependency graph and
> do a depth
> first traversal that adds leaf nodes without dependencies first then
> working your way
> up the dependency tree.  This would prevent the need to have to implement
> such a
> complex feature.  I'm fine with implementing the feature but it's going to
> take more
> effort than using this client side tactic.  There is some code similar to
> this in the
> maven plugin which loads the pre-fabricated schema partition during the
> build.
> If you can write code to actually push schema into ou=schema
> > > properly in the order of dependency leaves first then this would be a
> > > easier task for
> > > you than writing the control.
> >
> >
> > I was actually thinking of writing some kind of "Scheduler" to perform
> > request in a certain order, but it is really really painful.
> > Let's say for example, a user has entered a wrong OID for an attribute
> > type. He changes it in the plugin and pushes back the schema configuration
> > in the server. In order to do that, with schema check activated, the plugin
> > will need to:
> > - first, find all nodes (attribute types and object classes) that depend
> > on this attribute type
> > - second, remove all these nodes
> > - third, delete the entry corresponding to the attribute type with the
> > wrong OID
> > - forth, insert the new attribute type with the correct OID
> > - fifth, re-insert the removed nodes
> >
> Yes I see this is really painful.  :(.  You basically need to rebuild all
> the schema objects
> that depend on the schema entity you're changing.
> What about adding the functionality to the schema subsystem to rename an
> object and
> update the dependent entities that refer to it?  This would solve this
> particular problem
> which I think is the biggest one of all.  Other use cases like making a
> change to the
> characteristics of the AT or the OC besides the OID can be made without
> having to take
> these painful measures.
> I'm trying to find alternatives for this because this schema disabling
> functionality and it's
> impact to the server will not be trivial.  Perhaps this will be much
> harder to implement
> then to build a smart rename function into the schema subsystem.
> I can't imagine what it will be when there will be dozens of modifications
> > to commit... :(
> >
> > This is one of the examples that made me think about having the ability
> > to deactivate the check on the schema.
> > If this kind of mechanism could exist, committing the change would be
> > easier:
> > - first, delete the entry corresponding to the attribute type with the
> > wrong OID
> > - second, insert the new attribute type with the correct OID
> > And we're done...
> >
> > I was thinking of a control, to be able to choose whether or not
> > disabling the schema check on a 'per request' basis, but if it easier to
> > implement using a stored procedure, or modifying a special "configuration"
> > entry value, it's not a problem for me...
> > I don't know the inside of the server enough to see what costs more...
> Yeah you're onto something with the use of a stored procedure.  Perhaps we
> can combine some tactics.  Just thinking out loud here but we can have a
> cascade modify control.  Say you rename the OID or alias of a schema
> entity
> and you want the schema system to recursively update the dependencies
> like a cascade operation.  The schema subsystem can take this into
> account.
> We can even use this control in multiple places.  Like for example to do
> cascade
> deletes of schema elements.
> Thoughts?
> Alex

View raw message