• New Feature
  • Status: Closed
  • 0 Showstopper
  • Resolution: Fixed
  • ehcache-core
  • hsingh
  • Reporter:
  • December 01, 2009
  • 0
  • Watchers: 1
  • January 17, 2013
  • January 21, 2010

Description

Use new Hibernate SPI

The old one is deprecated and ehcache may get dropped from the Hibernate distro without an update.

Hey Greg…

On Wed, 2009-11-25 at 11:23 -0800, Greg Luck wrote: We (Me/Terracotta) are starting work on a new plugin for ehcache which
will unify the current one and the new one. It will work with
standalone ehcache but will also integrate in via a separate ehcache- terracotta module to their stuff. I am not following here what you mean by “current one” and “new one” really.

BTW, 1.7.1 introduces SLF4J which will work nicely with new versions.
Now, the current ehcache and the old terracotta plugin use the old API.

Are you planning on deprecating that and when? I was thinking we
should use the new API. Does that sound right? The argument here at
Terracotta is they used the old API last time because the new one was
backward compatible and it did not offer anything. If by “depracating *that*”, you mean the old SPI (CacheProvider), it is in fact already deprecated. I will probably not remove it for a few more releases. It’s backwards compatible because I wrote a bridge between the 2. Internally Hibernate always calls the new SPI. This “bridge” simply delegates the calls as est it can (there is not a 1-1 correspondence between the SPI contracts as the new SPI is far more expressive/verbose).

The new SPI is certainly more detail oriented. It tends to be more work to implement. But it allows the implementations very much freedom and expanded capabilities. The JBossCache/Infinispan implementations, for example, provide some very nice mixes of clustering certain cache regions but not others. I’m not going to go into all the benefits I see to the new SPI; I replaced the old one not just because I felt like it ;) It was a lot of work, but I feel its a much superior SPI. Brian Stansberry from the JBOss Cache team with whom I worked very closely in designing the new SPI agrees.

The Terracotta plugin also rewrites, using bytecode manipulation,
some of the Hibernate classes to remove unnecessary synchronization.
It seems a better answer would be for you guys to do that. I guess it depends where these synchronizations are. If it is in the bridge code or in the older “concurrency strategies” then I don’t think I would apply these changes back up stream. In the first case, we are talking about deprecated code with a clearly better alternative. In the second case, we could very well be talking correctness issues as well as the “deprecated code” aspect. If you can pin-point the code they change I can take a peek.

– Steve Ebersole [email protected] Hibernate.org

Comments

gluck 2009-12-01

Q&A

On Mon, 2009-08-31 at 10:39 +1000, Greg Luck wrote:

I have done my first commit to Hibernate core - to trunk, in the cache-ehcache module. It all works. Yaay!! :)

1) whether I should be committing to trunk and Yes

2) where do I put the changelog for the changes I make. Or do I create that in JIRA Yes, JIRA. Sorry should have mentioned this b4, but generally we only ever commit with a corresponding JIRA issue key in the commit message to allow tracking of work by issue. This allows the JIRA issues to be fully self documenting…

3) What is a good example for the new SPI and JPA? Infinispan? This is your copyright and license, so it makes sense for me to borrow freely from the other cache- modules JBoss Cache was the original implementer; the Infinispan intg is largely just copying from there as well. However, the above side of that argument is that the JBoss Cache intg evolved alongside the SPI, whereas since Infinispan is newer and coding against more stable contracts perhaps a bit cleaner (I do not know that for sure, just a supposition)

4) Does the new SPI take care of JPA2? Yes, the SPI already accounts for our requirements on the cache impls in regards to the Cache contract added in JPA2.

5) I assume I simply change the existing module over to the new SPI and stop implementing the old one. Certainly it should go in the same module. As to whether to continue to include the older implementation, that is up to you; my suggestion is to remove it.

Himadri Singh 2010-02-24

ehcache hibernate sample app in terracotta 3.2.1-ee kit works fine with hibnernate-3.3.2