Sorry, just realised this forum already exists - I started a new one on the 
same subject.  I'll cross-post here, pls ignore the new one I created.

Looking at JBCACHE-118 now.

There is a reported inefficiency of calling loader.exists() before calling 
loader.get().

We could call loader.get() directly, but since only attribs are stored in the 
cache loader, loader.get() returning null could mean the node does not exist or 
that the node does exist but doesn't contain any data. Which means that if 
loader.get() returns a null, we would THEN have to call loader.exist() to test 
whether the node exists in the first place.

1) The most efficient thing I can think of is to mandate in the API that 
loader.get() ALWAYS returns a Map of data, an empty map if there is no data. A 
null ALWAYS means the node doesn't exist. But this may involve patching our 
CacheLoaders (easy) and clients patching their custom CacheLoaders (harder).

The next best option depends on use case.

2) If most nodes contain data then it is best to do a loader.get() followed by 
(maybe) a loader.exists().

3) If most nodes are empty, then the current implementation of loader.exists() 
followed by loader.get() is better.

I have both implementations with me at the moment, with a new test case 
(CacheLoaderMethodCallCounterTest) that counts how many times each cache loader 
method is called and this is how I determined the above.

Does anyone have any idea of most common use cases? I hardly think many people 
would have caches of many nodes without any data in them (case 3 above) while I 
think the case of having nodes with data (case 2 above) is more common. I don't 
suppose there is any chance we could "enforce" a change in API semantics (case 
1, most efficient), is there? :) 

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3913698#3913698

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3913698


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to