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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
