December 01, 2009
January 17, 2013
January 21, 2010
Use new Hibernate SPI
The old one is deprecated and ehcache may get dropped from the Hibernate distro without an update.
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