[hibernate-dev] Spring Cache Abstraction
emmanuel at hibernate.org
Wed Feb 23 11:37:14 EST 2011
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
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.
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
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev