Hi,
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
www.iktek.com
directory.apache.org
