-
15. Re: uninitialized nodes
Thanks for the updates and sorry for messing up the jira issue
"manik.surtani@jboss.com" 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.
Why should it load it when I put? It doesn't even do that currently."manik.surtani@jboss.com" wrote:
Doing a put(node, key, value) is expected to return the old value under that key and hence the need to load.
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. I guess it did that because it thinks it should merge the map I gave it with the existing data. I need a way to tell it "just put this data and don't load anything". It should also not write that data to the cacheloader (this is yet another issue, I used a workaround for that too). The ultimate goal is to do my own optimized preloading of data from a database.
I wonder if the way to solve it is to have another "special" method like putForExternalRead. Anyway, as I said, my program works now with a cache listener and no cache loader. That will only run into problems if not all the data is present in the cache all the time. -
16. Re: uninitialized nodes
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 "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ... -
17. Re: uninitialized nodes
"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 load (because of return values needed)
* put(Fqn, Map) does not trigger a load
* get(Fqn, Key) does not trigger a load if the key is in memory, even if dataLoaded is false.
The last case can happen when:
1) create a new node - put(fqn, key, value)
2) node is evicted
3) put more data in the node - put(fqn, map) - node not loaded so dataLoaded = false.
4) get(fqn, k2) - if k2 exists in memory due to the put in 3), node is still not loaded and dataLoaded is left at false.
See UnnecessaryLoadingTest in CVS for details."aditsu" wrote:
It should also not write that data to the cacheloader (this is yet another issue, I used a workaround for that too). The ultimate goal is to do my own optimized preloading of data from a database.
This bit I don't understand. Even if you're doing a put(Fqn, Map) and you don't want to load data from the loader, I can't imagine why you wouldn't want the data written TO the cacheloader. Beats the fundamental purpose of a cache loader if this doesn't happen. -
18. Re: uninitialized nodes
"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 option. Perahps add a putQuietly() or removeQuietly() that have return types of void, although this clutters up the API which sucks."genman" wrote:
It would be nice if there was a "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ...
Well, unless disabling was conditional (i.e., disable for all get() calls) you may as well yank the interceptor out of the chain. -
19. Re: uninitialized nodes
"manik.surtani@jboss.com" 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(), which IMO should not be controlled by an option. Perahps add a putQuietly() or removeQuietly() that have return types of void, although this clutters up the API which sucks.
The AsyncCacheLoader has an option to allow remove() and put() (single key) operations to return null instead of the old value. This allows these operations to be queued rather than making the caller wait.
Anyway, I thought the point of the options was to send hints to the system, such as "Don't wait to put() if the node is already locked." I would think "I don't need to know the return value for this operation" would be a somewhat similar use case."manik.surtani@jboss.com" wrote:
"genman" wrote:
It would be nice if there was a "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ...
Well, unless disabling was conditional (i.e., disable for all get() calls) you may as well yank the interceptor out of the chain.
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 them. And rather than specify the ordering explicitly, the API would be add(Interceptor). You could have a remove(Interceptor) (symmetric call) as well that scans using object identity.
I do agree that bypassing certain interceptors should be drive by options, not an API call. (It'd be nice if this was done in some generic way. -
20. Re: uninitialized nodes
"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 them. And rather than specify the ordering explicitly, the API would be add(Interceptor). You could have a remove(Interceptor) (symmetric call) as well that scans using object identity.
I do agree that bypassing certain interceptors should be drive by options, not an API call. (It'd be nice if this was done in some generic way.
Off topic, but overhauling the interceptor chain is something I have planned for 2.1.0. See http://jboss.org/index.html?module=bb&op=viewtopic&t=112842 for early discussions around this.