directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Removing the last inner-operations, some insights
Date Mon, 07 Nov 2011 14:02:11 GMT
On Mon, Nov 7, 2011 at 8:26 AM, Emmanuel Lecharny <> 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 :
> 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
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

Kiran Ayyagari

View raw message