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 Mon, 09 Apr 2012 18:29:47 GMT
Le 4/9/12 7:57 PM, Selcuk AYA a écrit :
> We are thinking that the best thing to do is to forbid concurrent
> modifications of the Schema Registries. Ie, when such an operation is
> detected, then we block all the new incoming request, wait for all the
> currently running operations to be performed, and then do the modifications.
> Actually this is exactly what I wantrf to do. Getting the exclusive
> will quiesce all operations and chaging the registries will be an
> exclusive operation.However, this exclusiveness starts from
> DefaultOperationManager(that is where we have txn boundaries). I
> guess it would be legal to reference registries before entering
> operation manager and the chain right? In that case maybe I should let
> the cloning stay there for now..
Yep, probably.
>> This is a pretty conservative solution, but I don't see how we can do in any
>> other way before seriously rethink the impacts of any other solution...
>>> There might be some caches this wont work for.Like if we have an entry
>>> cache that sits above partitions, this wont work for this cache purely
>>> because of perf reasons. If this is the case for any cache, then that
>>> cache has to be made MVCC.
>> Yeah, that's probably mandatory. Sadly, the server performance will
>> essentially depend on the Entry cache to be present, instead of the page
>> cache that we have (deserializing an entry is an extremly costly operation).
>> We have to think seriously about having a MVCC cache. May be the small
>> experiment I did 2 months ago (MVCC in memory) could be reused ?
> Right now JDBM cache is MVCC.
Is it caching Entries ? AFAICR, the old JDBM code (before you modified 
it) was only caching pages (which contains serialized elements). If so, 
we are fine.

Emmanuel Lécharny

View raw message