[EMAIL PROTECTED] wrote :
| genman wrote :
| | There really should be options you can set to override loading from the
cache loader, or for ignoring the return values for Node.put(key, value) or
Node.remove(key) .
| |
| Yes, but then you change the behaviour of put() and remove(),
genman wrote : The thing with the removal and addition of interceptors is ...
the APIs are a little hokey. Working with index numbers isn't as nice as with
objects.
|
| I was thinking (and it's too late to change, but ...) Interceptors
themselves have a specific dependency or ordering to
aditsu wrote :
| I didn't put(node, key, value), but put(fqn, map). And it didn't load it
from the cacheloader, until I tried to get something.
|
That is a bug. (I've updated JBCACHE-1133)
This is now fixed in HEAD with an updated unit test, and now:
* put(Fqn, Key, Value) triggers a
genman wrote :
| There really should be options you can set to override loading from the
cache loader, or for ignoring the return values for Node.put(key, value) or
Node.remove(key) .
|
Yes, but then you change the behaviour of put() and remove(), which IMO should
not be controlled by an
There really should be options you can set to override loading from the cache
loader, or for ignoring the return values for Node.put(key, value) or
Node.remove(key) .
You should be able to remove the interceptors after you load to disable loading
and saving.
It would be nice if there was a
Thanks for this. Yes, this is a bug - JBCACHE-1133.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4063525#4063525
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4063525
___
Sorry, didn't see 1120 - marking it as a dupe.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4063527#4063527
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4063527
___
jboss-user
From your comment on JBCACHE-1120:
aditsu wrote :
| I don't think that's what I reported. I actually had these two problems:
| - AFTER I PUT A NODE IN THE CACHE, if I try to get the same node from the
cache, it still loads its data from the cacheloader
| - after I load a node's children
Thanks for the updates and sorry for messing up the jira issue
[EMAIL PROTECTED] wrote :
| This is not entirely correct since even when you first put a node in the
cache, it does need to (try and) load it from the cache loader in case it is
not really a new node but one that was evicted.
|
Filed this as JBCACHE-1120
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4060987#4060987
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4060987
___
jboss-user mailing list
It looks like the solution to all my problems is *not* to use a cacheloader at
all. I was preloading all the data anyway (in a custom and optimized way) so I
don't need to load further data, and for storing changes I found that I can use
a simple cache listener (the JBC2 CacheListener does a
Node.replaceAll(Map m) should not load the data.
Node.putAll() really is a merge operation, which is why the cache will load old
data when doing a getData()
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4058546#4058546
Reply to the post :
In order to call replaceAll, I need to have a Node first. And when I try to get
a node, the cache calls the cacheloader to load the data. This is exactly what
I want to avoid.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4058574#4058574
Reply to the post :
I also found that CacheLoaderInterceptor.loadChildren() actually calls
setDataLoaded(false) explicitly on every single child node, ignoring the fact
that data was already in memory.
It looks like JBC is trying every possible way to make sure that I can never
optimize data preloading, and it
JBoss Cache 2 (which is not in release yet) fixes some problems, such as the
hack where the map storage is used for book-keeping information.
This key is used to indicate that the data has not yet been loaded from disk.
You say this data is already in memory, how do you know? Also, the
You say this data is already in memory, how do you know?
Because I first put it myself in the cache. The data map already present in the
cache node (I checked with peek) has all the information I need, plus the
jboss:internal:uninitialized key which I don't need. When the cache finds that
Don't use the Node object directly in JBC 1.x. It was meant to be an internal
data structure object that got leaked into the API.
The correct approach is to use TreeCache.getChildrenNames()
In 2.x, we fully support access to Nodes, but this is different.
View the original post :
Don't use the Node object directly in JBC 1.x.
Ok, I guess I can use getChildrenNames(), but how can I get the data map of a
node?
Anyway, I'm already looking at JBC 2, and I found a lot of nice improvements...
maybe we'll switch to that. I'll adapt my code to it and see how it behaves.
View
Well, I have the same problem with jboss-cache-2.0.0.CR2: I put a node in the
cache, but when I try to get it later, it tries to load it from the cacheloader
because dataLoaded (in UnversionedNode) is false. How can I solve this?
View the original post :
19 matches
Mail list logo
