Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

OSCache vs. EhCache for Hibernate's 2nd Level Cache

Hibernate has a number of options for configuring its second level cache. For more information on configuring this, you might want to read John Ferguson Smart's article titled Speed Up Your Hibernate Applications with Second-Level Caching.

Up until today, I thought EhCache was the default cache provider, but apparently not anymore. From Hibernate's documentation:

Note that versions prior to 3.2 defaulted to use EhCache as the default cache provider; that is no longer the case as of 3.2.

So what's the default now? It can't be Hashtable since that's not for production use. I doubt it's OSCache since OSCache can't even get its patches into Hibernate. Looking through the release notes, I found out it's NoCacheProvider - seemingly because of an issue with EhCache:

Due to the upgrade to EhCache1.2 and its new non-singleton cache setup, we should no longer default the cache provider to be ehcache. Instead, default to NoCacheProvider.

That's reasonable I guess. EhCache added support for distributed caching in 1.2. It's a shame they didn't maintain backwards compatibility or they'd still be the default caching provider. Regardless, it doesn't matter who the default caching provider is because it's very easy to change it. Here's how it's configured on one of my projects:

<bean id="sessionFactory" 
    class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="configLocation" value="classpath:hibernate.cfg.xml"/>
    <property name="hibernateProperties">
        <value>
            hibernate.dialect=${hibernate.dialect}
            hibernate.query.substitutions=true 'Y', false 'N'
            hibernate.cache.use_second_level_cache=true
            hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider
        </value>
    </property>
</bean>

Of course, you can also configure it directly in hibernate.cfg.xml or a hibernate.properties file.

This leads me to the reason for this post:

What is the best 2nd level (clustered) cache to use for Hibernate?
I'm sure some folks will say Coherence, so let's narrow the question to what's the best open source option?

I've used OSCache in the past. It worked well, but it was kind of annoying that I had to patch Hibernate to make it work. The Hibernate folks say it's OSCache's fault, the OSCache guys say it's Hibernate's fault - so this issue will likely never get resolved. So what about EhCache? I don't know, I've only used it in a single JVM environment and haven't tried it in a clustered environment. Is there anyone using Hibernate + EhCache in production that can verify its effectiveness?

Of the options listed in Hibernate's documentation, the only other options seem to be JBoss TreeCache and SwarmCache. You can quickly eliminate SwarmCache since it never made it past 1.0 RC2 in October of 2003.

That leaves JBoss TreeCache, EhCache and OSCache as choices for a clusterable 2nd-level cache. OSCache is an invalidating cache, which definitely works - but might not work as you expect it to. JBoss Cache only seems to allow a replicated cache which also works. EhCache seems to support both. I don't know if invalidating or replicating is better, but I imagine replicating can get quite chatty if you're dealing with large amounts of data.

But wait - is there another open source option? According to Terracotta's CTO, Terracotta is much faster than JBoss Cache. However, if you read about it on DZone, you'll see that JBoss Cache has no "official" benchmarks.

So what's a developer to do? My current client likes OSCache, but I'm leaning towards EhCache. Which would you recommend?

Of course, if Coherence is only $1K per CPU, maybe that's the obvious choice? Unfortunately, I couldn't find their pricing using Google.

Posted in Java at Apr 17 2007, 01:59:27 PM MDT 14 Comments
Comments:

Matt, I've used both oscache and ehcache in production. Both worked very well. I can't conclude what's better... Nowadays I use ehcache, I think is easier to configure.

Posted by Ricardo on April 17, 2007 at 02:22 PM MDT #

Hey Matt,

Play with Coherence sometime and you will quickly see the value.

Of course you have already experienced that value indirectly a number of times - all those beers (etc.) you drank at the Tangosol JavaOne parties over the years ;-).

Posted by Rob Misek on April 17, 2007 at 03:48 PM MDT #

It's a pity Tangosol removed the pricing info from their website. It would nice if they were a little more transparent about it all...

Posted by Dan on April 17, 2007 at 05:36 PM MDT #

Believe me there have been lengthy discussions about that. The good news is that pricing is just a phone call away. Send me an email (minus the "-nospam" of course).

Posted by Rob Misek on April 17, 2007 at 08:30 PM MDT #

FYI, I normally don't make excuses for myself but Matt is right so I feel I must explain. Specifically, it is generally not kewl to assert we (Terracotta) are way faster than another technology without proof. I was in the middle of preparing a kit that includes JBoss's own tests and some summary tooling when I had a death in the family.

I will get it done by end of April and post about it. Thanks Matt for remaining objective even in light of my seemingly un-backed claims.

Also, Terracotta and EHCache have been integrated for folks who want to use EHCache for some things, Terracotta for others.

Posted by Ari Zilka on April 19, 2007 at 08:58 AM MDT #

Can someone educate me on how memcached fits in with this discussion? If Hibernate can't use it directly, can I get similar speed benefits by using it and not Hibernate level 2?

Posted by John G on April 19, 2007 at 06:17 PM MDT #

Rob: To me, non-public pricing information means "so expensive that they want your email address in order to be able to convince how much you really, really need it." Or in the short version: Too expensive to be worth checking out. I don't evaluate products that require me to give up my privacy to sales people.

Posted by Johannes Brodwall on April 20, 2007 at 07:11 AM MDT #

I appreciate your position. If you were not aware, we were recently acquired by Oracle (http://www.oracle.com/tangosol/index.html). So it looks like our pricing will be back online soon (http://oraclestore.oracle.com). In the meantime I could email you directly (http://www.brodwall.com/johannes/) if you like ;-).

Posted by Rob Misek on April 20, 2007 at 09:55 AM MDT #

Ok, so the doc is online now. Sorry for the delay: http://www.terracotta.org/confluence/display/orgsite/Info Last listing under "Articles and Whitepapers" --Ari

Posted by Ari Zilka on May 03, 2007 at 10:59 AM MDT #

About a year ago we decided to add a second level cache to our product. We wanted one that used multi cast and invalidation as we have multiple application servers running in a cluster. We went with OSCache as that was the only open source solution that supported multicast. It worked fine for a while. As we tried to support more load on our system it began to fail. I don't know if this was an artifact of threading bugs or invalidation messages failing to be received, but sometimes OSCache tries to do a lookup and fails with an exception. That was unacceptable since the exception bubbled up into our app. We didn't care if a lookup failed, it should have just logged the issue and pulled the object form the DB. Anyway, we hacked the code to catch the exception. Later we started seeing failures on put, tried wrapping that exception too. At that point we were having issues with data being correct between the app servers and started looking into EHCache.

We have been very pleased with EHCache. We are using multicast for app server discover, but using the built in TCP protocols for invalidation messages. We have not had any errors with EHCache. I highly recommend it.

We are using Hibernate 3.2 and EHCache 1.3.

Posted by Jeremy Conner on November 12, 2007 at 10:32 AM MST #

Ok, so the doc is online now. Sorry for the delay: http://www.terracotta.org/confluence/display/orgsite/Info Last listing under "Articles and Whitepapers" --Ari Posted by Ari Zilka on May 03, 2007 at 10:59 AM MDT #

Posted by 217.196.248.137 on December 18, 2007 at 10:59 AM MST #

I believe memcached is the direction to go as the distributed cache, since it does not have the GC problem, its size can increase unlimited and its high throughput.

I create a memcached hibernate provider, so far so good. I posted the java code in my blog.

http://hankliblog.blogspot.com/

Hope more people can start to use it so that it can become more and more mature. Though I have not find any issue to use it in my production environment.

-Hank

Posted by Hank on February 17, 2008 at 04:10 PM MST #

Hi Matt/All, I am tryin gto implement ehcache at home for simple struts, spring, hinbernate application. Can somebody help me by sending sample code... thanks in advance.. Harry

Posted by Harry on August 07, 2009 at 03:37 AM MDT #

Harry - take a look at AppFuse Light for the sample code you're looking for.

Posted by Matt Raible on August 18, 2009 at 10:54 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed