Hi, Re: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#... I think Brian has a good point here. We don't expose any internal information wrt each cache entry's expiry/eviction values. Brian has a good point that this could guide him in finding out which entries have been last been used, how long they've been in memory and how it could tweak expiration/eviction accordingly. If we don't do anything, I think we run the risk of people being forced to get hold of the container, looping through it and getting information that they need from inspecting internal classes. So, I'd suggest that we add a JMX method to CacheDelegate called something like: Map<String, Map<String, long>> getTransientAndMortalityInformation(). (I'm open to suggestions to other names. This is the 1st thing that came to my mind) This would return a Map where the key is the toString form of the cache key and the value part is a map where individual transient/mortal properties are returned. I.e. [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456], Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567], ...] We could event add calculated properties such as 'age' which is current - created. This would vary with each call obviously. As indicated in the forum entry, at least based on this use case, I don't see an immediate need to query this type of information given a key, although could be potentially useful for other use cases. The reason this would not help much right now is because it is Hibernate that creates the keys of 2nd level cache (i.e. CacheKey) and these are nor meant to be recreated externally, so it'd be hard for external apps to get something out of the Infinispan cache directly without going through the Hibernate integration layer. My suggested JMX method could allow for individual transient/mortality information to be queried by tools, or other client jmx code. Maybe some tools could use that to create a table or something like that which could be ordered based on a column? i.e. age. Also, tools or client jmx code could convert those longs into whatever they want: seconds, minutes...etc The reason I think JMX is a good candidate here is this is inherently monitoring information and it allows us to expose internal information via primitives without having to expose internal classes. Thoughts? Cheers,