@Cachable has no effect
Description
Attachments
relates to
Activity
Brett Meyer July 8, 2014 at 3:10 PM
Bulk rejecting stale issues. If this is still a legitimate issue on ORM 4, feel free to comment and attach a test case. I'll address responses case-by-case. Thanks!
Brett Meyer April 7, 2014 at 5:42 PM
In an effort to clean up, in bulk, tickets that are most likely out of date, we're transitioning all ORM 3 tickets to an "Awaiting Test Case" state. Please see http://in.relation.to/Bloggers/HibernateORMJIRAPoliciesAndCleanUpTactics for more information.
If this is still a legitimate bug in ORM 4, please provide either a test case that reproduces it or enough detail (entities, mappings, snippets, etc.) to show that it still fails on 4. If nothing is received within 3 months or so, we'll be automatically closing them.
Thank you!
Julien Kronegg November 27, 2011 at 1:08 AM
Hi Steve,
I had a similar issue on JBoss AS7 (default provider=Hibernate4) with @Cacheable on a JPA entity and the property <property name="javax.persistence.sharedCache.mode" value="ALL"/> (or any other value) in persistence.xml: the L2 entity cache does not work.
But if you use <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> in the <persistence-unit> tag instead of the javax.persistence.sharedCache.mode property, and add the property <property name="hibernate.cache.use_second_level_cache" value="true"/>, the L2 entity cache works. See my answer to Paul Bakker's post.
So maybe that's not the @Cacheable annotation which does not work, but the javax.persistence.sharedCache.mode property.
Steve Ebersole June 15, 2010 at 7:07 AM
Its not just difficult, its impossible. Why? Well say you chose READ_WRITE as the default as you suggest. The problem is that if you run with JBossCache or (I believe) Infinispan, READ_WRITE is not a valid option. The underlying problem is that (1) not all providers support all access types and (2) we do not really define a "hierarchy" amongst the access types to be able to switch over from one to the other automatically if a provider did not support the specified one.
And its not just an issue with READ_WRITE itself as the specific access type.
PaulP June 12, 2010 at 6:00 PM
I agree it's difficult to choose a reasonable default because of the different implementation and consequences. Do you have any idea which setting "most" people use? READ_WRITE seems reasonable to me, but I'm really not sure about how people use it. Besides that it would be good to log a warning during startup that a default strategy has been used.
Making the default override-able globally in persistence.xml would be very useful.
The JPA 2.0 @Cachable annotation has no effect at all. Just putting @Cachable on a class is not enough to enable caching. You must also configure a concurrency strategy with either @Cache or a hibernate.ejb.classcache setting in persistence.xml.
If those settings are in place, @Cacheble still has no effect. Entities are cached, but @Cachable(false) doesn't change this behavior.
I included a Maven example project that tests this behavior. The project has two profiles to switch between Hibernate and EclipseLink:
mvn -P hibernate clean test
mvn -P eclipselink clean test