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 08:17:10 GMT
On 1/3/11 2:39 AM, Alex Karasulu wrote:
> What's giving me an icky feeling inside is that #2 is making a read
> operation induce writes (although DSA driven maintenance operations) and
> hence causing us to consider one offs with the way a change log works. It's
> also something to be considered for replication as a change to be ignored.
Changelogs works the exact same way. The current tests I wrote 
(add/del/lookups) prefectly reverts even if a write is done when reading 
infos. The very same for replication.

Consider that the server sees no difference if the write is done because 
someone has read some info. They are atomic modifications anyway.
> My whole religious issue with approach #2 is that it's essential an
> optimization for an administrative operation that is forcing us to settle
> for this path because of a lack of solid atomicity based on local
> transactions in the server.
Not only. It's mainly a way to avoid a huge penalty caused by a massive 
change on a million entries server, making the users paying a small 
price once when reading info instead of blocking the whole server until 
all the entries are updated.
> We're shifting many ideals we all believe in if
> I am not mistaken to optimize a seldom performed operation that usually
> occurs during outage times.
Again, I explained in some previous mail that it's not a trade. If an 
admin want to have the entries being updated immediately, then he has 
the possibility to do a full read. Or we can, as I suggested, implement 
option #3 and make the server update the entries immediately. Option #1 
is a one way road with no escape...

Emmanuel L├ęcharny

View raw message