On Mon, Jan 3, 2011 at 2:09 AM, Emmanuel Lécharny <firstname.lastname@example.org>
We have three options here :
On 1/3/11 12:57 AM, Alex Karasulu wrote:
On Mon, Jan 3, 2011 at 1:27 AM, Emmanuel Lecharny<email@example.com>wrote:
(I still have in mind to add an optional computation of the entries when an
Could you elaborate on this? I did not quite understand what you mean by "an
AP or a Subentry are modified, to avoid a postponed evaluation).
optional computation of the entries".
- 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.