Add a property to define cache implementation in persistence.xml

[lukasj]

The cache implementation for the second level cache currently has to be configured via vendor specific properties but the semantics of the Cache are already reflected in the interface javax.persistence.Cache. The cache implementation should be configurable via persistence.xml.

I propose the property javax.persistence.cache.provider and the value of it should be the class name of the cache provider that actually implements javax.persistence.CacheProvider.

The CacheProvider interface could look similar to the RegionFactory interface hibernate actually uses.
Including the option to specify cache implementations in a stadardized way will improve the portability of applications and also make people to use the standard JPA provider of a container instead of packaging their own one in their applications.

[lukasj]

@glassfishrobot Commented
Reported by c.beikov

[lukasj]

@glassfishrobot Commented
@arjantijms said:
Maybe it's also convenient to take JCache into account, instead of or perhaps next to a new javax.persistence.CacheProvider? Just like JPA 2.1, JCache is slated for inclusion into Java EE 7.

[lukasj]

@glassfishrobot Commented
c.beikov said:
I wasn't aware of the status of JCache back when I made this issue. Integrating JCache is IMHO the right way!

[lukasj]

@glassfishrobot Commented
This issue was imported from java.net JIRA JPA_SPEC-32

[lukasj]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/32
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @ldemichiel

[gavinking]

Integrating JCache is IMHO the right way!

So my thoughts on this issue are:

1. Hibernate has had support for JCache (along with other options) for quite a long time, so if JPA said something about using JCache as the second-level cache provider, that would be totally fine from our point of view.
2. On the other hand, after a Google search, I don't see anything about support for JCache in EclipseLink, so I would not be surprised if this is something they don't want.
3. In general, Hibernate and EclipseLink have extremely different philosophies with respect to caching, to the extent that the stuff that was added in JPA 2.0 is nearly useless in Hibernate.

Let's consider what was already done in JPA 2.0:

• The @Cacheable annotation with no members indicating semantics is essentially useless, and we tell everyone to use our own @Cache annotation instead. Similarly, EclipseLink has its own @Cache annotation with a completely different list of settings.
• The JPA SharedCacheMode enum defines options like ALL and DISABLE_SELECTIVE which go completely against our whole philosophy of how a second-level cache should be used. Only ENABLE_SELECTIVE should be used in Hibernate.
• The Cache interface is OK in principle, but it must be extended in Hibernate because we store entities and collections in separate regions, and the Cache interface seems to quite implicitly assume that collections are stored in the same region as their owning entities. So there's a lack of portability here.

In summary, the previous attempt at standardization was an almost-total failure. It was probably bound to fail, and in my opinion should probably have not been attempted. I guess I dropped the ball here by not paying closer attention to this part of JPA 2.0.

I'm therefore not sure what would be gained by adding more second-level cache functionality to the spec, especially if it would again be something only applicable to certain JPA implementations.