Hi guys, I've walked around eviction policies and here are some thoughts 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: http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache. 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). 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. 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'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'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 this is feasible. Perhaps in the case of PojoCache in which object are introspected anyway? Any thoughts? Cheers, Mircea