"ben.wang(a)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(a)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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...