I was looking at the Laravel docs and I see a cache driver and a redis class. Looking at the cache class it seems like I could just use this to store things in Redis as I just change which driver I am using for caching to the already added Redis driver. However there is also a separate Redis class. Why is there a separate redis class? If the cache class can do the same thing and allow me to also swap which driver I use if ever needed, what reason is there to use the Redis class?
Maybe I am missing something here but I am just confused which one I want to use to store key's and data in redis? I am using Laravel 5.
From the documentation, the Cache class (Facade):
provides a unified API for various caching systems.
One of which is Redis. Another is Memcache. This class serves as a wrapper to abstract functionality to allow you to be technology agnostic. Ideally so you can swap out the underlying caching system without changing application code.
However, by abstracting you can lose functionality specific to a technology. So the Redis class is specific to Redis. If you require Redis specific functionality, you'd need to use this class directly.
Related
have been searching through the documentation but to no avail... How should I inject Redis cache through Dependency injection instead of using the Redis facade?
You can find all underlying classes in https://laravel.com/docs/5.5/facades#facade-class-reference. For Redis, it's \Illuminate\Redis\RedisManager. But for caching, I recommend using the default cache driver \Illuminate\Contracts\Cache\Factory because Laravel will namespace the keys behind the scene. If redis isn't the default cache driver, you may specify the store like this:
$cache->store('redis')->get('foo');
So,
I'm trying to convert our existing caching (ehcache) to ignite cache, and migrating to spring annotations. I'm running into some difficulty making the annotations work the same as our existing caches though - our existing caches are created automagically whenever we cache something of a new class, and the new cache has the same name as the object's class.
All the current cache logic (along with most of the normal CRUD operation logic) is in an abstract class that's extended for all our persistent objects. In researching the spring annotations, though, it seems like I need to define the cache name on the method - which obviously doesn't work for the abstract class, unless I want all our objects to be in the same cache (possible but definitely not ideal). Ideally I'd specify the cache name as "#this.class.toString", but SPEL isn't allowed in the cache name, like it is in the key.
It seems like the only way to resolve the cache dynamically is by creating your own cache resolver, but for some reason IgniteCache doesn't extend springframework Cache, but javax Cache, and the cache resolver has to return the former. So I'm not even clear how Ignite cache works with spring annotations at all?
This seems like a pretty straightforward use case to me, so it seems weird that spring annotations force me to provide an explicit name on the method, when I'd assume most applications of any significant size are abstracting their persistence methods, and I feel like I must have missed some crucial documentation, but I sure can't find it. Is there a way to specify the name of the cache on the concrete implementation, but keep the caching annotation on the abstract methods?
Thanks!
Your question is quite dense and it's not very clear what you're trying to do. What is "your existing caching" for a start? You need some way to flag the places where you actually cache things I guess. I assume you already understood you need to put a cache annotation there.
As for automatically creating the cache, I wouldn't switch to a different caching system and trying to implement that. Try to migrate first to the cache annotations with your existing cache infrastructure and then migrate to ignite.
Let's pretend you do both still. You are right CacheResolver is the way to go and it can adapt to either a regular org.springframework.cache.Cache or a javax.cache.Cache. Once you have a setup that works, I'd do the following:
In your CacheResolver implementation, inject the cache manager that has been configured
Based on the method call, figure out the cache name to use (get the return type of the method, extract the FQN)
Check if the cache manager has such cache. If it does, return that. If it doesn't create a new cache and add it and then return that
If you're using JCacheCacheManager, you can invoke addCache to create a new cache and then wrap the result in JCacheCache to comply with the signature of CacheResolver.
Last note: automatically creating the cache based on the FQN seems a bit fragile to me, especially if you have sub-classes. You need a bit of control on the caches you create and the settings you apply to them (expiration, size, etc).
Mule got inbuild object stores to cache data, But what is the purpose of using custom object stores under caching strategies? If possible, Please mention a usecase.
Custom object stores are useful when you want to use a custom persistence mechanism for your ObjectStore's
By default Mule provides two implementations, in-memory and a file based persistent store.
One possible use-case is, if you use Enterprise Edition have clustering enabled, you also have the ability to share these stores across multiple Mule nodes. However if you do not use EE or clustering but still want to share data between multiple Mule's, then you will need to use a persistent object store that can be shared across multiple mule nodes.
The ObjectStore interface has many implementations so you can choose a persistence mechanism that best suits you. Examples include Redis, Ehcache, Mongo, Cassandra, JDBC. More on this here:http://java.dzone.com/articles/synchronizing-data-across-mule
Ryan has given the correct explanation.. I just want to add:-
Mule uses object stores whenever it needs data to persist for later retrieval.
Custom Object store can be configure using Java classes and you can customize the Object store as per your need..
You can customize it and control your Cache and the Cache Keys, as well as store and retrieve the data, log you Cache keys and Cache contents, list you Cache keys etc from the Java class and that means full control on the Custom Object store ..
Please go through the following links :-
http://ricston.com/blog/cache-scope-ehcache/
http://java.dzone.com/articles/cache-scope-ehcache
http://www.mulesoft.org/documentation/display/current/Mule+Object+Stores
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.
Spring provides a useful feature of Cache Abstraction
But what I could not find is a provider agnostic way to get live cache statistics. Essentially I just want to show a list of all the cache names and their corresponding keys with the count of hits, misses, and sizes (in kb) either on a web page or via JMX. I know Ehcache does provide this feature and if I use ehcache API inside the code I can get it (have already used it in the past). But I believe using Ehcache API inside the code takes away the whole notion of the Spring framework's cache abstraction.
The only common, provider-agnostic thing you have is CacheManager interface, which provides the following method:
Collection<String> getCacheNames()
It returns a collection of the caches known by the cache manager.