On 02/23/2011 04:19 PM, Sanne Grinovero wrote: I believe the link is http://static.springsource.org/spring/docs/3.1.0.M1/spring-framework-refe... Gustavo

Is it just me or did they just make a weapon to shoot everyone in their foot ? Caching entities like that is dangerous and really hard to catch....weird how neither their docs, blogs or javadocs mentions the problem of accidentally sharing out JPA entities across sessions.... /max On Feb 23, 2011, at 17:41, Daniele Dellafiore wrote:

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: