"[EMAIL PROTECTED]" wrote : This may be a bug in 1.1, but it is definitely
calling the CacheLoader in 1.2:
|public Node get(Fqn fqn) throws CacheException {
| | MethodCall m=new MethodCall(getNodeMethodLocal, new
Object[]{fqn});
| | return (Node)invokeMethod(m);
| |
"[EMAIL PROTECTED]" wrote : This may be a bug in 1.1, but it is definitely
calling the CacheLoader in 1.2:
|public Node get(Fqn fqn) throws CacheException {
| | MethodCall m=new MethodCall(getNodeMethodLocal, new
Object[]{fqn});
| | return (Node)invokeMethod(m);
| |
Since my original posting was truncated, here comes the rest:
it executes the n.createChild(...) but never calls the CacheLoader to get the
data. Do I misunderstand what the TreeCache.get(Fqn) method is supposed to do
(ie fetch the data from 2nd store if not available in the local cache)?
I'm r
Is there a specific reason why my posting was truncated?
Is there something wrong with the forum code?
/Erik
"nine_mirrors" wrote : Howdy all,
|
| I'm (still) implementing a cache loader and trying to get a feel for how it
works.
| I'm wondering about TreeCache.g
Howdy all,
I'm (still) implementing a cache loader and trying to get a feel for how it
works.
I'm wondering about TreeCache.get(Fqn). It does not seem to call
CacheLoader.get(Fqn) (which it should in my opinion).
My code:
TreeCache cache = new TreeCache();
.
.
Node node = cache.get(new F
"norbert" wrote : It's absolutely unefficient to store a whole table in a
single node - Transactional locking, eviction and Cacheloading work on
Node-level, not key/value-pair level. As a result every 'put(Fqn,key,value)'
would lock your entire data if the Fqn being used is a constant.
|
|
"norbert" wrote : You are right, as of JBossCache 1.1 get(Fqn,Key) is actually
only being called by the JUnit-testcases. In respect to TreeCache itself it's
(yet) redundant.
|
| Instead of returning null your CacheLoader should return a prefilled Map of
Key-Value-pairs when get(Fqn) is bein
Howdy all!
background: In our db we have a rather large table (>500k entries). Said table
is growing over time but not all entries are live. We are aware of this so we
prune the table about once a week. The only live entries that we are sure of at
run-time are those that are actually requested
