directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] [Schema] Update mechanism
Date Wed, 25 Nov 2009 18:03:05 GMT

I'm implementing a middle term solution atm.

When a modification is made on the server (whatever it is, add, delete, 
modify...), the following actions take place :
1) The registries is cloned
2) The modifications are applied to the cloned registries
3) A check is done to see if the registries is still consistent (so far, 
it does not differ from what we had, except that this sanity check 
protects the admin)
4) If the check is ok, then the same modification is applied on the 
current registries
5) done...

So, what will happens if an admin make a mistake is that he might have 
issues with the current ServerEntries the server is manipulation (cache, 
session, etc), but right now, as soon as the rest of the server is 
working, ie as soon as we assume that the tests are passing fully, then 
we can use this as a base for the next step. In any case, the trunk is 
not protected *at all* against bad schema modification, so we will just 
have a safer schema management than the previous version, with the same 
risk (plus some other improvements).

The next stpe will probably be to think about those listeners we have to 
implement, and it's far from easy...

Will keep you updated !

Alex Karasulu wrote:
> Thinking more about how to update the schema and the mechanics involved
> along with the various trade offs.  Here's how this should progress:
> Schema Change Steps
> (1) A schema change operation arrives and changes are performed on a cloned
> set of registries where the impact of the change is calculated in terms of
> the total number of indirect dependents affected.
> (2a) If the operation is consistent then a schema-txn-begin message is sent
> to all listeners informing them of the OIDs impacted by the schema change
> calculated in the first step.  This lets objects dependent on these schema
> entities to respond to the situation. This message is delivered
> synchronously.  Access to the old Registries is provided before the swap in
> case the object needs them via the SchemaManager handle if they are exposed.
> (2b) If the operation leaves the schema in an inconsistent state then no
> message is sent to schema listeners and the schema change is rejected.
> (3) The schema registries are swapped out.
> (4) The SchemaManager then sends a schema-txn-commit message to all
> listeners to now be able to access the modified schema elements they're
> interested in from the newly swapped in registries.  This message is
> delivered synchronously.
> Schema Change Responses
> (1) Invalidate the object in question so all using/run processes and caches
> can reset or update themselves via the acquisition of a new valid object to
> continue the process.
> (2) Make the object depending on schema objects valid by updating stale
> references and hope for the best.  Sometimes timing will cause certain
> failures but this is really OK with us since this is a rare situation to
> update the schema.
> SchemaListener Interface Methods
>    schemaChangeBegin( SchemaManager sm, List<String> oids );
>    schemaChangeCommit( SchemaManager sm, List<String> oids );
> Pulled these out of my arse so please elaborate.
> Regards,

cordialement, regards,
Emmanuel L├ęcharny

View raw message