[hibernate-dev] Spring Cache Abstraction

[Emmanuel Bernard]

It kinda like the declarative aspect of it though there are a lot of nasty strings all around :). The rest is not really new so all old school issues apply.

As usual for higher level caching you need to manually handle data eviction which is likely be a source of bugs. 
They also don't say if they share the same entity instance or serialize / deserialize but unless this is read-only results (ie not modifiable by the user), you'd better be careful. Likewise, make sure you have a multi-threaded implementations of the data structure returned.
They don't seem to discuss transaction or clustering. I imagine they let the underlying cache provider do the work.

More specifically with Hibernate, if you use such facility within a open session in view pattern, expect weirdness to happen as well as method level cached objects are not going to be managed entities:
 - not updated transparently
 - the same instance might be reattached to several session => badaboom

A good summary of where cache could happen in an application is available here
http://docs.jboss.org/seam/2.2.1.Final/reference/en-US/html_single/#cache

Due to all the potential issues, I tend to favor HTML page fragment caching:
 - it's higher up the food chain hence likely more efficient
 - many of the issues declared above don't apply (not all disappear though)

But it's sure a useful tool for niche requirements that can live with such constraints.

Emmanuel

On 23 févr. 2011, at 17:04, Marc Schipperheyn wrote:

> It would be interesting to have the Hibernate team comment/blog on the new
> Spring Cache Abstraction functionality and how it relates to Hibernate
> managed entities. Perhaps some strategies, etc. It's very attractive to just
> cache entities in stead of caching entity values with the second level
> cache.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev