Re: [hibernate-dev] Exposing transient/mortality information externally
Be cautious about exposing cache contents (even just keys) via JMX. If
you do, make it something that people can turn off, without turning off
the basic JMX interface. Reason is the same as in recent discussions
about providing access to the cache itself via JMX. People who deploy a
JMX-enabled cache are not necessarily expecting that any code that can
access the MBean server can also inspect cache contents. For example, a
simple session id string is a likely key, and session ids are
essentially a security token that shouldn't be exposed willy-nilly.
In general, for the Hibernate 2LC use case, IMHO it's better if the
Hibernate statistics API is improved, rather than having people access
the cache directly. How the data is stored in the cache should be an
internal implementation detail that can be changed when needed. That's
part of why your addition of eviction configuration to Hibernate
Configuration properties was so nice.
All that said, if information like
[Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
...]
is readily available internally, having a mechanism for authorized users
to get at it sounds pretty cool. :-)
On 11/26/2009 03:16 AM, Galder Zamarreno wrote:
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.
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,
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat