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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev