Which is better to use - EHCache, OSCache or Swarmcache

[asmuts]

We discussed some of the drawbacks and benefits of the JBoss caching option son the JCS user list last year:

http://mail-archives.apache.org/mod_...3.mbox/browser

[gmatthews]

There's also a new supa dupa version of JBoss Cache coming out shortly.

See http://www.jboss.com/wiki/Wiki.jsp?page=JBossCache

[asmuts]

What specifically makes JBoss cache better? Is it easier to use, more scallable, more feature rich, or faster than other caches such as JCS? The answer to all of the above seems to be no.

I don't want transactional distribution. It simply cannot scale given current harware, especially via JGroups.

I don't want the AOP logic, since it solves an uncommon problem (where you change only a small bit of a large object but have to send the entire thing over the wire) at the cost of added complexity and a performance penalty for the common case where you want the entire object to go over the wire.

It's too tied to JBoss and I would never sell my soul to any container.

It isn't as fast as JCS.

It ins't plugable like JCS.

There may be some cool disk cache features that come with the JBoss cache, but I've never looked into how well they perform.

[asmuts]

The JCS site has been updated with a getting started guide, an faq, and several other new documents:
http://jakarta.apache.org/jcs/index.html

[gmatthews]

What specifically makes JBoss cache better?

I wasn't so much pointing out which one is better.

I was pointing out that if you need to run two boxes, you choices are:
1. JBoss Cache, or
2. JBoss Cache, or
3. ...you get the idea...

You probably pointed out several aspects of caching that should be considered, but you've got to get past the "are you running 2 or more boxes?" question first before they're even relevant.

Also, last time I looked swarmcache wasn't transactional, which counts it out if the data in your system has any sort of value and/or the customers of your system are likely to get pissed off if problems occur relating to non-transactional caching. Given JBoss Cache as an alternative, that pretty much counts it out of the list.

[asmuts]

I guess I didn't make myself clear. JCS is a distributed caching system. I'm using it to distribute data across clusters of various sizes. I pointed out why I do not want a transactional distribution mechanism. . . .

Take a look at the documentation:

http://jakarta.apache.org/jcs/index.html

[gmatthews]

asmuts, I see now you're a developer on JCS. That explains your post.

I also assumed from the poster's original question that they want a cache that plugs into Hibernate, given their mention of all of the Hibernate caches (except JBoss cache).

Maybe you can clarify if JCS plugs into Hibernate, or if there are future plans to allow it to be used as a 2nd level cache for Hibernate.

btw, the following is just plain wrong. JBoss Cache isn't tied to the JBoss app server. You can use JBoss Cache as a standalone plug in to Hibernate.

It's [JBoss Cache] too tied to JBoss and I would never sell my soul to any container.

[asmuts]

That I started JCS is irrelevant to whether or not JCS is better than JBoss cache. I asked for reasons to think that JBoss cache is better. Accusing me of bias is not a reason to think that JBoss is better. Perhaps this might help:

http://en.wikipedia.org/wiki/Ad_hominem

Can you offer any reasons why JBoss is better? What makes it better? Can you address the fundamental design flaws that I pointed out? I never said that you must use it inside of JBoss. . . .

[gmatthews]

Can you offer any reasons why JBoss is better?

I'll try. Firstly, my requirements and goals are to operate a production system on commodity hardware, and safeguard data that is extremely valuable to our customers.

We also can't handle the system load on one box, so operate multiple boxes behind an Apache front end.

So, I've decided we need transactional clustering to deliver the above requirements.

The only choice seems to be JBoss TreeCache, which works pretty well.

I think the next JBoss TreeCache release supports eviction from the cluster as opposed to replication across the cluster which will be good.

I'm hoping it will scale reasonably well since we're scheduled to do a country wide sales and marketing rollout around April so will likely have some interesting performance figures to share by then.

Regards,

[thejavafreak]

Great choice

Spring Framework 1.1.1 allows for configuring EHCache using IOC. Take a look at package org.springframework.cache.ehcache (in cvs) for more details.

OSCache also support integration with spring.