directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Subentry cache : one step further
Date Mon, 03 Jan 2011 00:09:51 GMT
On 1/3/11 12:57 AM, Alex Karasulu wrote:
> On Mon, Jan 3, 2011 at 1:27 AM, Emmanuel Lecharny<>wrote:
>> Hi,
>> (I still have in mind to add an optional computation of the entries when an
>> AP or a Subentry are modified, to avoid a postponed evaluation).
> Could you elaborate on this? I did not quite understand what you mean by "an
> optional computation of the entries".
We have three options here :
- the current trunk implementation modifies the impacted entries 
immediately when a Subentry is added/removed/modified (using the 
SubtreeSpecification). It's costly, but only when we add/remove/modify a 
- the current branch I'm working on is using a differed computation, ie 
the entry relation to subentries is compted the first time the entry is 
accessed (either during an addition or a modification, or when read). 
That means the first read of an entry will imply a write on disk, the 
next read will be as fast as a normal read. OTOH, the first read of an 
entry is always costly, as we have to read the entry from the disk 
(unless it's in cache).
- the third option, if we don't want to impact users when adding a 
subentry when the server is running, is to do as it's done in trunk, ie 
update all the entries when adding a subentry. But this would be an 
option that can be activated on the fly (by modifying th server 
configuration, or by sending a control with the subentry operation).

I suggest we go for option #2 atm, assuming that implementing #3 is easy 
and won't imply a huge refactoring, as the mechanisms used to update the 
entries is already implemented.
>> That's it, just wanted to update you guys.
> Thanks,

Emmanuel L├ęcharny

View raw message