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.
As of today, the clone is mainly used to check that the registries
remain consistent after the changes. Calculating all the impacted
elements is a bit complex...
(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.
If the object has already been checked by the SchemaInterceptor, and if
the schema modification makes this object to be inconsistent, we won't
be able to fix that, as the chek has already be applied.
SchemaListener Interface Methods
schemaChangeBegin( SchemaManager sm, List<String> oids );
schemaChangeCommit( SchemaManager sm, List<String> oids );
Pulled these out of my arse so please elaborate.
My guts say that it's far too complex to implement right now. My kidneys
feel that it might even don't work correctly : too many corner cases...
IMHO, we shoudl try to get the server back on rail, even without all
those dynamic schema modifications, except for the additions operation
and for the schema enabling operation.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
