directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: TXN WORK: advice needed on how to deail with logical caches
Date Thu, 12 Apr 2012 16:11:02 GMT
On Thu, Apr 12, 2012 at 6:50 AM, Emmanuel Lécharny <> wrote:
> 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.
> fine.
>> - 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 ?

yes this is correct.

>> - 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 ?
I would prefer to implement it as is today because I feel it is going
to be easier for me.

> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

View raw message