directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Subentry cache : one step further
Date Mon, 03 Jan 2011 00:38:28 GMT
On Mon, Jan 3, 2011 at 2:09 AM, Emmanuel L├ęcharny <elecharny@apache.org>wrote:

> On 1/3/11 12:57 AM, Alex Karasulu wrote:
>
>> On Mon, Jan 3, 2011 at 1:27 AM, Emmanuel Lecharny<elecharny@gmail.com
>> >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.
>
>
It's up to you but IMO I don't think this option of delaying updates with
subentry changes is really worth the complexity and it also introduces other
serious issues. I wanted to express this thought but you seemed very
interested in this direction so I let it be.

Just as a quick idea of what I was thinking. Sometimes a search with the
right parameters pursuant to a subentry alteration affecting the selected
region may trigger the entire area to be computed anyway making the lazy
computation effectively the same thing as eager computation. But this time
the computation effort is felt on a search operation. This will make our
performance metrics tests even harder to interpret down the line as well.

Furthermore don't we want to know if a subentry altering operation succeeds
when the administrator performs it? It might be nice to have the operation
block as well so the admin knows when the operation completes so he can let
users back on the system. Also when we  get local transactions implemented
in the server subentry alterations should be tied to a single atomic
operation. If something fails for some reason or another down the line while
making the updates don't you want to know immediately and roll back?

Just some food for thought.


>>  That's it, just wanted to update you guys.
>>>
>>>
>>>  Thanks,
>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>


-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu

Mime
View raw message