This question is with reference to Simple Spring memcached.
I have a scenario where a list of deals are cached for user using the userId as the key. Now in case a deal data is updated I need to flush the cache for all users since this would affect deals data for all the users.
How can I achieve this with SSM annotations. The invalidate*cache and update*cache options seem to invalidate/update key specific cache entries whereas I need to clear the entire cache.
Currently it's impossible in plain SSM to flush entire cache using annotations, if you require such option please create a feature request on: https://code.google.com/p/simple-spring-memcached/issues/list
There is another way to flush entire cache by using SSM with Spring Cache as describer here: https://code.google.com/p/simple-spring-memcached/wiki/Getting_Started#Spring_3.1_Cache_Integration.
Just change allowClear to 'true' and use #CacheEvict(value = YOUR_CACHE_NAME, allEntries = true)
Related
I have a Spring Boot application that is caching some values such as <UserId, MyPojo.class>.
Example MyPojo fields:
id
code
If a change is made to MyPojo.code then I want to clear the cache for all users that have that MyPojo.id.
I've looked at #CacheEvict annotation with a condition, but that seems to be only for deciding whether to evict cache on some condition without checking what is present in the cache itself.
Another option would be to iterate through every cache entry and check the value and clear that key, but that seems expensive.
Any suggestions?
While implementing Hazelcast for the first time in set of web APIs, the usage of Map and Cache is inconsistent.
For example, creating a cache using SpringCacheManager results in the creation of a map
var sCache = springCacheManager.getCache("testCache");
sCache.putIfAbsent("test", "test2");
However, creating a cache using the CachingProvider CacheManager results in the creation of an actual cache that must be opened and closed (as per the documentation)
try (var cache = Caching.getCachingProvider().getCacheManager(null, null,
HazelcastCachingProvider.propertiesByInstanceName("hazelcache")).createCache("actualCache", config)) {
cache.putIfAbsent("test", "test");
}
Another example, using the #Cacheable annotation will create a map, even though the documentation outlines the usage of a Cache. The following code will successfully return the first computed value using a Map in hazelcast. A cache is never used.
#Cacheable(value = "counter")
public Boolean test(Integer addTo) {
counter += addTo;
return counter % 2 != 0;
}
Is there a formal definition within Hazelcast of a cache vs a map? Are both usable for the same purpose?
The image below contains a view into a test Hazelcast Management Center that shows the above components, namely the maps and caches. These are all generated by the same client.
test
There are Cache, Spring Cache and Map to consider here.
For Cache, Hazelcast is an implementation provider for the Java caching standard, JSR107.
These show as "Cache" on the Management Center, and if you run hazelcastInstance.getDistributedObjects() they'll be of type ICache. It's in the Hazelcast documentation here.
For Map, Hazelcast provides a data structure IMap which is mostly a superset of java.util.Map. These show as "Map" on the Management Center.
Spring also provides caching, and you can set CacheType for JSR107 or directly with Hazelcast, or allow Spring to pick. When Spring uses Hazelcast directly, it will use IMap not ICache for storage.
If you pick JCache or configure Spring to use JCache, then you get standards compliant behaviour. You have caching, and can easily swap caching provider from Hazelcast to something else should you want to.
Map gives you operations such as executeOnKey to update one or more entries in situ. If the entry is a compound object but on a small part is changing, this can be a more efficient way to update it than sending the whole value.
I am trying to load my cache off of a cold start, prior to application startup. This would be done so values are available as soon as a user accesses a server, rather than having to hit my database.
#Cacheable functionality from Spring all works great, the problem is how I manually store objects in the Cache so that they can be read when the function is executed.
Spring is storing these objects in bytes, somehow -- and I need to mimic this while I manually load the cache. I'm just trying to figure out how they process the return objects, in the function, to store into the cache in a key,val pair.
You can programmatically access any cache by using Spring's CacheManager.
See https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/cache/CacheManager.html
var cache = cacheManager.getCache("foo");
cache.put(key, value);
I was able to solve this problem by storing values as a string key and object value -- which works wonderfully with Spring #Cacheable annotations. Objects are casted into the return types by Spring if they are found within the cache.
I realise #Cacheable annotation helps me with caching the result of a particular method call and subsequent calls are returned from the cache if there are no changes to arguments etc.
I have a requirement where I'm trying to minimise the number of calls to a db and hence loading the entire table. However,I would like to reload this data say every day just to ensure that my cache is not out of sync with the underlying data on the database.
How can I specify such reload/refresh intervals.
I'm trying to use Spring boot and hazelcast.All the examples I have seen talk about specifying LRU LFU etc policies on the config file for maps etc but nothing at a method level.
I can't go with the LRU/LFU etc eviction policies as I intend to reload the entire table data every x hrs or x days.
Kindly help or point me to any such implementation or docs etc.
Spring #Cacheable doesn't support this kind of policies at method level. See for example the code for CacheableOperation.
If you are using hazelcast as your cache provider for spring, you can explicitly evict elements or load datas by using the corresponding IMap from your HazelcastInstance.
I have been considering implementing EhCache in my Grails domain objects like this :
static mapping = {
cache true
}
I am not too familiar with exactly how this caching mechanism works and was wondering what a good rule of thumb is in determining which domain objects would benefit from being cached. eg, objects that are accessed rarely.. often... ?
Thanks!
Caching only works for get() calls by default, but queries use the query cache if you update them with cache: true (criteria and HQL).
cache true creates a read-write cache but you can configure a read-only cache with
static mapping = {
cache usage:'read-only'
}
The read-only cache is good for lookup data that never changes, for example states, countries, roles, etc.
If you have domain classes that update, create, or delete frequently, query caching will often be slower than not caching. This is because changes like these cause all cached queries to be cleared, so you're often going directly to the database anyway. See http://tech.puredanger.com/2009/07/10/hibernate-query-cache/ for a more detailed description of this. For this reason I rarely use query caching and often disable it completely with
hibernate {
cache.use_second_level_cache=true
cache.use_query_cache=false
cache.provider_class='org.hibernate.cache.EhCacheProvider'
}
Domain classes that are "read-mostly" are the best candidates for read-write caching. The caches get cleared for each update, create, and delete, but if these are somewhat rare you'll see an overall performance boost.
Hibernate has an API to monitor cache usage. The http://grails.org/plugin/app-info and http://grails.org/plugin/hibernate-stats plugins make the information available and you can use the approach there in your own code.