Hi Daniel
From: "Daniel Hoppe" <[EMAIL PROTECTED]>
> I did not follow the ObjectPool discussions to closely, so I hope I'm not
> missing the point.
I didn't really follow the ObjectPool discussion either.
> As far as I got it
>
> - the pool hands out an object exactly once. The object is unavailable for
> others until it is returned
> - the cache may hand out an object several times. The object is not
> exclusively used.
Thats my understanding too.
In caching the same (read only) object is returned to all callers, rather
than removing it per caller and putting it back again when they've finished
with it. The two are quite similar from an implementation perspective but
semantically quite different.
There could be some potential sharing of common interfaces or implementation
code across the two.
> James, what do you think of making a cache JMX compliant?
Sounds a great idea - particularly as the JMX compiance part could be a
configurable, optional extra. I like the idea of being able to manage the
cache & see whats being cached, per region, in different JVMs. I've never
looked at JMX yet though.
> I'm working on a
> cache which is supposed to buffer data in a content management system. The
> cache is supposed to store objects which are quite expensive, the caching
> will be crucial for application performance.
I've pretty similar needs & goals. Caching of expensive objects. (e.g. XML /
XSLT documents for example).
> That's why I need to have a
> good overview on what's happening inside the cache, not just as some
> debugging output but rather in a fashion that can be remote monitored and
> integrated with monitoring tools.
Agreed.
> I plan to implement the measures
> - objects in cache,
> - cache hits,
> - invalidations,
> - cache misses of key that have not been in the cache yet,
> - cache misses due to a constraint of maximum cache entries.
>
> The last two points might seem a little bit strange at the first thought,
> but I think they can make a sense in certain situations. If a cache has
the
> option of either using soft references or a maximum number of entries,
there
> will be a certain amount of cache misses due to either a limited heap size
> in case of soft references or a limited number of maximum entries allowed
> (which is most probably related to heap size as well.
Agreed. I'd like these kind of caching strategies and policies to be
configurable at deployment, on a per region basis. Kinda like log4j has
category based logging configuration, I'd like the same for caching.
FWIW theres a SoftRefHashMap in the collections project too that might be
useful.
> With this monitoring information a sysadmin could easily determine if e.g.
> an installation would benefit from an increased heap size.
Agreed.
> To distinguish between both types of cache misses it is of course
necessary
> - to keep a list of keys which are already known to the cache
> - to have a mechanisim to finally drop keys after a certain while (e.g.
the
> key of a deleted page in a content management system should not remain in
> the cache for weeks and months).
>
> This implies that the value object needs to have noticeably higher amount
of
> heap consumption and computation time on creation than the key, otherwise
> the cache would of course not make much of a sense.
>
> In my current prototype I'm supplying three types of caches, a cache
which,
> when full,
>
> - drops the oldest value objects,
> - drops the ones with the longest interim since the last hit
> - drops the ones with the fewest number of total hits
>
> I can configure which kind of references are used (strong, soft, weak).
>
> I like the idea of a cacheloader. Thought of that as well, but somehow did
> not have the drive to implement that in my ejb environment yet (might be
> messy if the cacheloader has to deal with FinderExceptions of EJBs).
I like the idea of the CacheLoader interface throwing exceptions, so it
doesn't need to catch them then a cache region can decide what to do about
it. (e.g. take down the cache, alert the JMX agent or whatever).
> What I did not fully get so far is the idea of the cache-regions. I always
> thought of putting a cache instance to some central location (Web
> Application Context, JNDI Tree, e.g.), but maybe my view is to J2EE
focused
> on this. I'm a little bit sceptical about a cache being a static member as
> there are some restrictions on that in the EJB spec..
Agreed. You can always use that lovely "transient" keyword ;-)
A CacheRegion could be initialised & stored in a Web Application Context or
JNDI tree if you like.
The main idea behind the 'region' was to (a) avoid lookups to find it when
it makes sense to do so and (b) allow per-region based configuration. Rather
like log4j's categories, you might want to have different regions for
different Java packages, or semantic names and so on.
> Altold, do you think we are trying to achieve something similar or is my
> approach too much heavy-wheight for your needs?
I think we're pretty much aiming at the same thing. I just want to keep the
public API nice and simple so it can be used anywhere (application, applet,
servlet, EJB) and has low dependency and can be either really simple (e.g.
just one LRUMap instance) or quite complex (using notification & messaging
systems, JMX, J2EE et al) with possibly hierarchial dependency tracking and
all sorts of other gizmos.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
