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