Hi, with a little digression, here are some general ideas on the schema changes:
I think we should handle schema changes in a way something like this: 1)quiesce all ldap operations on all partitions. 2)change schema, and maybe update registries. 3) Check for inconsistency but if anything goes wrong after updating registries, reinit the registries from on disk schema partition. 4)let all operations go ahead. Reasoning: *Almost every code has read dependency on the schema registries, so when a thread changes the schema and the registries, every operation will be affected by the change. So I do not think letting any other operation to be concurrent with schema change makes sense. *At step 3 above, schema entry having a child is only one case of failure. Currently we also seem to clone the registries before doing any change to them. Ignoring all the current problems because of lack of isolation of schema change, lets say we do the following: a)check if hasChildren is false b) clone registries, update them and check for inconsistency c) if everything is OK, update registries d) Update data on disk. If something went wrong during step d and operation failed, cloning the registries and doing the update on the cloned registries wouldnt save us and reinit of registries would be necessary. P.S. With txns, hasChildren is not necessary because it is implemented above the partitions using the indices exposed by partitions. On Fri, Dec 2, 2011 at 11:32 AM, Pierre-Arnaud Marcelot <[email protected]> wrote: > > On 2 déc. 2011, at 10:28, Emmanuel Lécharny wrote: > >> On 12/2/11 10:14 AM, Pierre-Arnaud Marcelot wrote: >>> +1 >>> >>> Definitely a good utility method to have. >>> >>> But I feel that the verification that the entry is a leaf and does not have >>> any children, in the case of a delete operation, should be done by a higher >>> level interceptor (or class). >>> I'm not sure this scenario should be verified on each partition type but >>> that a higher class (DirectoryService maybe) should take the responsibility >>> to ask the underlying partition if the entry is a leaf and then ask it to >>> delete the entry. >> >> This is what was done before, but using a search request, which was costly. >> If we have a hasChildren(Dn) on the Interceptor interface too, then it would >> be possible. > > Indeed, and depending on the partition implementation, we might not even have > to run a one level search to find the children (me may have some kind of > index that we could use on some sort of partitions). > > Regards, > Pierre-Arnaud > > >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >> >
