directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: We may need to add a hasChildren() method in the Partition interface
Date Fri, 02 Dec 2011 10:40:39 GMT
On 12/2/11 11:03 AM, Selcuk AYA wrote:
> 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.

Sure. But we can even be a bit more strict : schema deletion could also 
be forbidden (this is what AD does, btw). In fact, we could even just 
disable a schema element, but not delete it, so that entries depending 
on a deleted schem element is still valid.
OTOH, changing the schema live is a dangerous operation, most of the 
case the server is usually shutdown, and restarted when the schema is up 
to date (which doe snot solve the case of entries pointing to removed 
schema elements, btw).

We may want to add a kind of barrier which is raised when a schema 
modification starts (ie, all the new operation are enqueued, waiting for 
the schema modification is done), and the schema modification is waiting 
for all the pending operation to be completed (and that include the 
paged search). But I don't think it's mandatory : the schema is used 
through the registries, which is always consistant (see down this mail)
> 2)change schema, and maybe update registries.
We first update the registries, to check if its consistant or not. If it 
is, then we update the LDIF partition, and we then switch the updated 
registries with the current registries.

So in fact, the steps are :
1) clone the registries
2) update the cloned registries
3) check if it's consistant
4) if so, update the schema on disk
5) then switch the registries (it's a protected section, the registries 
variable is volatile)

and we are done.
> 3) Check for inconsistency but if anything goes wrong after updating
> registries, reinit the registries from on disk schema partition.
we just don't switch the registries in this case : the cloned registries 
is simply ditched
> 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.
the main issue is o-how do we deal with a failure in the middle of the 
modification of the schema on disk ? We don't have any way to restore 
the original schema. We may need to copy the whole schema on disk (a 
backup) before modifying it, so that if we have a failure, we can safely 
restart the server from the backup ( which will not be a backup, btw, 
but the *real* schema, until the check is done, where we can safely 
discard the 'backup' and use the new schema.
> P.S. With txns, hasChildren is not necessary because it is implemented
> above the partitions using the indices   exposed by partitions.


Emmanuel L├ęcharny

View raw message