directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Removing the last inner-operations, some insights
Date Mon, 07 Nov 2011 13:26:52 GMT
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


Mime
View raw message