openjpa comes with its own cache implementation. But it will also easily integrate with ehcache and other third-party cache providers.
What are the main advantages of using ehcache vs OpenJPA's implementation? is it a scalability issue?
Thanks
Ehcache can run in a distributed mode which is more scalable and the default OpenJPA cache implementation is limited by the size of the JVM's memory. I believe that running with the default cache you will see much better performance that running with a distributed ehcache.
Related
I want to try Ehcache in distributed form. Can someone suggest me if EHcache (Not the BigMemoryMax) works in distributed mode.
I am looking for only open source product. I am not looking to buy a Bigmemory Max or Terracota server, which will give me a off heap access, which i dont need as of now.
If so, please provide the version, url and some guide/examples to implement distributed Ehcache.
Thanks...
Ehcache website is your best starting point:
Ehcache 2.10.x has open source clustering support with Terracotta 4.3.x
Ehcache 3.1.x has open source clustering support with Terracotta 5
What is the difference between the Ehcache and Guava Cache? In which scenarios would I use which type of caching?
Note: I am a developer working on Ehcache
The answer to your question depends on which features your cache needs to have inside your application.
Guava caches have all the basic caching features.
Ehcache has more advanced features - see 2.x line or upcoming 3.x line
Multi tier caching (disk in 2.x, offheap + disk in 3.x)
Clustering (2.x for now, soon in 3.x)
Refresh ahead or scheduled refresh (2.x for now)
JSR-107 API
So my advice is to look at your needs, play with both and then decide.
I want to cluster EHCache in Play Framework 2.x web application in several node. Why everyone recommend to avoid to use EHCache as a distributed cache in Play 2.x clustered web application?
I use nginx proxy to serve request across Play node and i want to make default EHCache of each node share its content.
Well according to this EHCache page, using EHCache in distributed mode is a commercial product. So if you want to use a free distributed cache, you need something different like Memcached or Redis.
My experience deploying a (Java)Play 2.2.3 to Amazon EC2 was terrible with EHCache. It requires a few workarounds with the localhost resolve (going su for each of your nodes - hard work when you have a few dozens of servers) and regardless, being free only for standalone version without ostensively letting us know upfront is a big no-no for me. I'm done with EHCache.
Edit: moved to Redis in 2015 (thanks #Traveler)
I am not aware of any Play Framework issues here, but the use of ehcache 2.x should fine as you can set it up with JGroups (faster than RMI) and use invalidation mode (infinispan slang).
Invalidation is a clustered mode that does not actually share any data at all, but simply aims to remove data that may be stale from remote caches. This cache mode only makes sense if you have another, permanent store for your data.
In ehcache 2.x you can set up invalidation mode with replicatePuts=false in your jgroups config.
In ehcache 3.x they do not have such a mode. You have to set up a commercial Terracotta server which is a distributed cache. So all date is moved between nodes and the terracotta server.
We tried it once and failed terribly.
As ehcache2.x is no longer active we just switched to Infinispan which has all features of ehcache2.x and a lot more.
So my recommendation: Use ehcache 2.x or infinispan. Do not use ehcache 3.x
Directly quoting from ehcache's website [source]:
The idea here is that your caches are set up in a cache hierarchy.
Ehcache sits in front and memcacheg behind. Combining the two lets you
elegantly work around limitations imposed by Google App Engine. You
get the benefits of the speed of Ehcache together with the umlimited
size of memcached. Ehcache contains the hooks to easily do this. To
update memcached, use a CacheEventListener. To search against
memcacheg on a local cache miss, use cache.getWithLoader() together
with a CacheLoader for memcacheg.
This seems to imply that using ehcache with memcached would be faster than using memcached alone. Why would ehcache be faster than memcached? The way I see it, both are in memory caches so why the performance difference?
Ehcache often runs in the same jvm process with the application,so it does not need serialization and io costs.
When using Ehcache with memcached,some objects are stored in ehcache heap and others are in memcached. so mix ehcahe and memcached will faster than only use memcached.
Runs ehcache and application in the same JVM process is a way to exchange RAM space for time,
but you can not put too many data to ehcache because you need to consider replication between servers.
I am planning to implement the Cache in the web application.
I have already used the Hibernate EHCache in one of my previous web application.
Now a days, recently i came to know that in latest Spring release there is Cache Abstraction layer.
Hence i would like to is it just wrapper of Hibernate EHCache or it is Cache features provided by Spring itself.
If different then would like to know which is best or better option to use Cache ?
Also, i came to know from few articles that Hibernate EHCache not supporting clustering, is it ? Because clustering required for big Web Application.
I have used Spring 3.1 and Hibernate 3.3 in Web Application.
Hibernate and EHCache are different things.
EHCache is the cache provider, i.e. the actual implementation of the cache.
Hibernate can use multiple different providers for the L2 cache, including EHCache.
Spring Cache is a framework for caching method calls. It can use multiple different providers, including EHCache.
EHCache offers distribution (clustering) in several modes, from basic JMS-driven synchronization to Terracotta BigMemory distribution. Hibernate L2 cache should support clustering.
Spring Cache has nothing to do with Hibernate, but you can use Hibernate L2 cache and Spring Cache (method caching) in parallel with EHCache as the underlying provider for both.
Just to add, for database-level caching using hibernate, hibernate/JPA second-level cache seems more appropriate. Because it manages data caching at entity level at the persistence context level (JPA APIs), so there are very fewer chances of inconsistency in database and cache, since hibernate manages it well.
But if we use spring cache for database caching, then we always have to ensure every method operating on database need to be annotated with appropriate cache annotation (For example, #CacheEvict for remove), so there are chances of missing annotations and causing inconsistency.
Also, spring cache can only be used on public methods, since it backed my AOP (We can use AspectJ though to solve this).
Hibernate caching continues to work with Spring using EhCache (or another caching provider). It offers a 2nd level cache for storing em.find(key) entities and relationships (#Cache annotations or XML), as well as query caching if you q.setHint("org.hibernate.cacheable",true). These are integrated and well-documented. Spring caching is not needed for this.
But Spring provides method caching which is independent of Hibernate caching, and can still use EhCache as the caching provider (sharing EhCache with Hibernate). This can be a little confusing because the EhCache configurations are overlapping, but essentially Spring Caching allows you to independently cache the results of methods that are marked as #Cacheable.
Note 1: Spring/Method caching is not integrated with Hibernate. Results cached with method caching are not recognized or maintained by Hibernate.
Note 2: Hibernate Query caching is not recommended for highly distributed systems without a good understanding of how the caching is used. It increases the risk of deadlocks due to the use of a shared entity timestamp cache that Hibernate maintains to keep track of when the cached query results should be evicted.