On 1/3/11 12:57 AM, Alex Karasulu wrote:
On Mon, Jan 3, 2011 at 1:27 AM, Emmanuel Lecharny<[email protected]>wrote:
Hi,
SNIP
(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
subentry.
- 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,
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
