Hi guys,<br><br>I&#39;ve walked around eviction policies and here are some thoughts <br><br>1) There is an eviction policy algorithm more efficient than LRU (which I found quite popular) - Adaptive Replacement Policy. The basic idea is to not rely only on the time of last access to the node, but also on the number of time(frequency) a given node was accessed. Here it is a nice description of how it works: 
<a href="http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache">http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache</a>. <br><br>2) One other type of eviction which I found handy is a time based eviction, i.e. the node will be removed from the cache after a certain time(countdown starts when it is added).&nbsp; A common use case for this is when one needs an info from database, which might be changed, but is not critical to have it visible in real time.
<br><br>3) Memory based eviction policy. Very useful in the case in which cache is used for storing very heterogeneous objects - from the size point of view. If the objects are large one is assured that the cache won&#39;t exhaust system memory and in the case of small objects the cache manages to store much more than it does if it would use a static defined policy, like LRU. The most appropriate way (I found) for measuring object size is shipped within JDK5, through 
Instrumentation.getObjectSize. The MAJOR drawback is performance: method returns only the size of the base object; for all aggregated objects one will have to iterate recursively over the object graph and calculate size - costly both as performance and as memory. I don&#39;t have the complete picture on the JBC usage scenarios (
e.g. this might be useful in a scenario in which addition is rare and memory size is critical) so perhaps you guys can point out whether or not&nbsp; this is feasible. Perhaps in the case of PojoCache in which object are introspected anyway?
<br><br>Any thoughts?<br><br>Cheers,<br>Mircea<br><br><br>