directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: A control for enabling/disabling dynamic schema check ?
Date Tue, 12 Jun 2007 09:07:05 GMT
Oh and benefit (7) when put into the server all clients can benefit from
this control
like JNDI clients as opposed to having this capability with just Studio: not
that I
personally would use any other client :-D.

Alex

On 6/12/07, Alex Karasulu <akarasulu@apache.org> wrote:
>
> Actually come to think of it the use of a cascade req. control along with
> pushing
> 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 will
>      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
> rollbacks
>      can be enabled and there is no inconsistent state for the schema
> (regardless
>      we can still make sure the schema is not inconsistent while
> performing these
>      operations in the server - just more work)
>
> Some drawbacks:
>
> (1) the server's schema subsystem must have code added to it to handle
> this control
> (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 managing
>      these kinds of operations/checks
> (3) time :)
>
> Alex
>
> On 6/12/07, Alex Karasulu <akarasulu@apache.org> wrote:
> >
> >
> >
> > On 6/12/07, Pierre-Arnaud Marcelot < pa@marcelot.net> 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
> >
> >
>

Mime
View raw message