Hi guys,
this morning, while enduring the morons who were using their phone in
the train, I had time to check the last parts were we are doing
inner-operations. Here is the list of places we use this feature :
* in SchemaSubentryModifier.[add, addSchemaObject, deleteSchemaObject,
delete], add, delete, operation
The reason we do a inner-operation is that we have to update the
cn=schema part (in memory, this is the registry) and the ou=schema (a
partition, stored on the disk). Currently, we start with a cn=schema
modification, entering the chain with a add or delete request, then in
the schemaInterceptor, we continue by doing a add/delete operation on
the chain for the ou=schema part.
It goes through the following interceptors when called from the
AbstractOperationContext :
NI, AI, RI, ACI, DAI, API, EXI, OAI, SI, -> [NI, RI, API, OAI, CAI,
SI, EI, TI, CLI, JI, nexus]
At this point, thee is no reason to go through the NI and RI for direct
modifications on the schema. Same for the API. The real problem is that
we have to change two entries : the cn=schema and the ou=schema entry.
One is on disk, the other one is deduced from the Registry (cn=schema).
We could probably combine those two operations into one, assuming that
modifying the ou=schema and cn=schema are having the same impact :
- NI : we should only go through this interceptor only once.
- AI : The authentication is only due when the operation is issued. No
need to do it twice.
- RI : The schema is always local. This interceptor will never do
anything for schema modifications.
- ACI : it makes no sense to protect the virtual cn=schema entry.
Instead, all the ou=schema operation should be protected. Thus, we
should check the authorization globally, whether the user requested a
modification on ou=schema or cn=schema (they are both impacted anyway).
- DAI : same as above
- API : This interceptor does nothing when we have a schema modification
: not the ou=schema and cn=schema can contain an administrativeRole
AttributeType. In fact, we should bypass it.
- EXI : This should be bypassed, as we will detect that the entry exists
or not later on.
- OAI : We just need to update the ou=schema operational attributes, no
need to do anything for cn=schema, so we can just go through this
interceptor once
- CAI : must be bypassed. No collective attribute for the schema
- SI : This is where we will modify the cn=schema part (in memory) when
the modification on disk have been successful. That means we should
first try to modify the ou=schema entry, and if it succeeded, then we
can update the registry.
- EI : This will fire some events if there are some registered on ou=schema
- TI : Same as EI, on any modification done on ou=schema
- CLI : Register the revert operation for modification made on ou=schema
- JI : Same as CLI
We could probably do the same for the delete operation.
We can't modify a schema element, nor we can rename or move it.
Base line, we should probably be able to get rid of re-entrant operation
for any of the schema modifications.
If we do so, then there will be one remaining reentrant operation, in
MaxImmSubFilter.getImmSubCount, search operation. I'm quite sure we can
get rid of it too.
As soon as we are clean, we probably can remove the InvocationStack, as
suggested by Kiran.
Note that it does not change anything related to the TXNs.
I'll update you guys as soon as I have done some experiments. Feel free
to comment !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
