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.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::