On Mon, Nov 7, 2011 at 8:26 AM, Emmanuel Lecharny <[email protected]> wrote: > 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. > I have started with this one, but there is a problem with the testGrantTuple() test in MaxImmSubFilterTest class This is due to the fact that MockDirectoryService will have a null PartitionNexus. We can solve this issue if we move MaxImmSubFilterTest to core-integ > 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 > >
-- Kiran Ayyagari
