I'm in the process of upgrading JavaLite ActiveJDBC from EHCache 2.x to v 3.x.
It looks APIs changed dramatically, and I can find equivalents of what I need in v 3.x, except for one: How to clear all caches? For example, in v2.x, I could do this:
net.sf.ehcache.CacheManager cacheManager = net.sf.ehcache.CacheManager.create();
//... code
cacheManager.removalAll();
How can I do this in EHCache 3?
Clarification: CacheManager.removalAll() is a method that not only clear caches, but removes them completely. It is deprecated in the latest version and replaced with CacheManager.removeAllCaches() to better indicate its purpose.
Caches will no longer be alive and cannot be used anymore if you were to keep a reference to one of them.
The equivalent in Ehcache 3 would be to invoke: CacheManager.close() which would close all caches and then release all resources held by the CacheManager.
Hard to conclude with the disconnect between what I understand the stated goal to be (clear data from caches) and the Ehcache 2 method used (remove all caches) if Ehcache 3 satisfies it.
Related
Can EhCache 3.x caches be configured to implement a refresh operation (see https://github.com/google/guava/wiki/CachesExplained#refresh for an example as implemented using Guava) - i.e. if the entry is expired, return the expired entry until the refreshed entry has been retrieved? This looks like it might have been possible under the 2.x versions using a decorator like http://www.ehcache.org/apidocs/2.10.3/net/sf/ehcache/constructs/refreshahead/RefreshAheadCache.html (although even this doesn't really match my use case, it looks like it always performs the refresh rather than only on expired entries) but I can't find any equivalent for the more recent releases.
Is this something that should be handled at a higher level? In the context of a Spring Boot application, is there another mechanism by which this could be done while using EhCache as the backing implementation?
I want to upgrade the Ehcache Version to 3.x from 2.10.x and I dont find the support for RMI/JMS replication (RMICacheReplicatorFactory and JMSCacheReplicatorFactory) in Version 3. if Ehcache 3.x does not support RMI/JMS cache replication what is the best alternative (hazelcast/memcached/redis)
The support is indeed discontinued mostly because it gave zero ordering and consistency guarantees. The alternative for Ehcache is Terracotta clustering. It offers a proper model where ordering is guaranteed and consistency can be tweaked somewhat.
As to whether it will fit your use case, that's entirely up to you to determine.
Note: I work on Ehcache and Terracotta
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 have always used the java singleton class for my basic caching needs.
Now the project is using ehcache and without looking deeply into source code, I am not able to figure out what was wrong with the singleton pattern.
i.e What are the benefits of using the ehcahce framework except that the caching can be done by using xml configuration and annotation without writing the boilerplate code (i.e a static HashMap)
It depends on what you need from your caching mechanism. Ehcache provides a lot of cool features, which require a lot of well designed code to do it manually:
LRU, LFU and FIFO cache eviction policies
Flexible configuration
Persistence
Replication
many more ...
I would recommend you go through them at http://ehcache.org/about/features and decide do you really need something in your project.
The most important one:
The ability to overflow to disk - this is something you don't have in normal HashMap and writing something like that is far from trivial. EhCache can function as simple to configure key-value database.
Even if you don't use overflow to disk, there's a large boilerplate to write with your own implementation. If loading the whole database would be possible, that using memory database with persistence on write and restoring on startup would be the solution. But memory is limited and you have to remove the elements from memory. But which one, based on what? Also, you must assert cache elements are not too old. Older elements should be replaced. If you need to remove elements from cache, you should start from the outdated ones. But should you do it when user requests something? It will slow down the request. Or start your own thread?
With EhCache you have the library in which all those issues are addressed and tested.
Also there is a clustered closed source version of ehcache, which allows you to have a distributed cache. That might be one reason you might want to consider using ehcache.
We have been using EHCache with CF8 for a while now with no issues.
We are now moving to CF 9 and it seems that the baked-in version of EHCache with CF 9 is actually conflicting with our EHCache setup.
So is there:
Any way to disable the baked-in version of EHCache? This would be a temporary solution.
If we use the CF9 baked-in caching, is there any way to specify more than one cache in ehcache.xml and most importantly, to put into that specific cache via the tag?
Many thanks in advance.
Just create the CacheManager using the overloaded constructor which takes the path to your ehcache config file as an argument
http://ehcache.org/apidocs/net/sf/ehcache/CacheManager.html#CacheManager%28java.lang.String%29
This will create a non-singleton CacheManager which will play nice with CF9
Are they using the default classpath:ehcache.xml location? If so try seeing if you can initialize your CacheManager first then their code may end up just re-using your instance.