directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: TXN WORK: advice needed on how to deail with logical caches
Date Thu, 12 Apr 2012 13:50:38 GMT
A bit late, but still, some more thoughts about the entry cache... Let 
me add some comments in this mail to be sure I understood what you have 
in mind...

Le 4/8/12 9:16 PM, Selcuk AYA a écrit :
> I am about to revisit the logical caches issue. My plan is to do the
> following to handle all these caches in a generic way:
> - a singe version number is kept for all caches.

The latest, I guess.
> - a thread starting a txn read locks an internal readwrite lock.
> - when a thread needs to modify a cache, it ugrades its lock to
> exclusive lock.
It will block all the read on the cache until the cache update is done, 
right ?
> If it detects a version change during this time, it
> throws a conflict exception. If no, it bumps up the version number and
> changes the cache.
as the write lock will be exclusive, I assume that the cache 
modification will be done by one single thread. Now, there is one race 
condition that can occur if the thread modifying the cache has a 
revision number lower than the current revision number. That means the 
cache has been changed by anothe rthred. The timeline for such a case 
would be :

time arrow --->
T(r1) o-------------[r1] modify cache
T(r2)      o-----[r2] modify cache

When t(r1) tries to modify the cache, the cache already has a higher 
revion in it (r2), even if the T(r1) thread has been started before.

In this case, we will throw a conflict exception on T(r1)

Is that what you have in mind ?
> - After committing, thread releases the lock.
> -If thread aborts its txn, then it notifies interceptors in its
> interceptor chain of the abort. Any interceptor can then rebuild its
> cache from what is on disk at this point. I am assuming this is
> possible for all logical caches.
What about aggregating all the cache update we do in all the 
interceptors in one single CacheInterceptor, responsible for the update 
of all the caches ? The idea would be to globally lock the cache one 
single time instead of doing so in many places. Accessing the caches 
will be done through an helper class masking the access to internal 
caches, with proper locks shared by all the threads.

Sounds good ?

Emmanuel Lécharny

View raw message