directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <ayasel...@gmail.com>
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 <elecharny@gmail.com> 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.
yes.

>
>> - 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
> www.iktek.com
>

Mime
View raw message