[jboss-dev-forums] [Design of JBossCache] - Re: Thoughts on 2.0 API
genman
do-not-reply at jboss.com
Wed Oct 4 14:10:48 EDT 2006
"ben.wang at jboss.com" wrote :
| I don't quite agree that the current way of creating a default cache is that bad though. If you don't pass in the start flag then the default is to start the cache life cycle. Isn't this what you are asking for?
|
I guess I wasn't paying attention. :-/
"ben.wang at jboss.com" wrote :
| Sure this would be nice. Manik can say more definitely. But we do have a plan to elevate the Region into first class construct.
|
This would probably be my biggest suggestion. I'm not sure what the roadmap is, I did poke around JIRA and find these two issues:
http://jira.jboss.com/jira/browse/JBCACHE-64
http://jira.jboss.com/jira/browse/JBCACHE-86
Both of these suggest you'd want to extend Region in the future.
I also think that something like this:
Cache tokyo = Cache.getRegion("/tokyo").getCache();
would be really cool. Something like how List.subList is done. It'll allow you to segregate cache access better in your application.
A couple of other things:
| putIfNull -> putIfAbsent
|
The difference between the key doesn't exist and exists but points to null is a subtle one. The JavaDoc seems to imply "putIfAbsent"...
| * Puts a key and a value into the current node's data map if nothing exists
| under the key.
| * Does nothing if the key already exists.
|
you could simply "borrow" the javadoc from 1.5 ConcurrentMap:
| If the specified key is not already associated with a value, associate it with the given value. This is equivalent to
|
| if (!node.getKeys().contains(key))
| return node.put(key, value);
|
Actually, one thing I did notice is that "put" no longer returns the old value, was that intentional?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976123#3976123
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976123
More information about the jboss-dev-forums
mailing list