Spring 3.1 M1 is out with some very useful features. One of the coolest feature in the latest release is comprehensive Caching support!
Spring Framework provides support for transparently adding caching into an existing Spring application. Similar to the transaction support, the caching abstraction allows consistent use of various caching solutions with minimal impact on the code.
The cache is applied to Java methods, reducing the number of executions based on the information available. Spring checks if the given method is already executed for given set of parameters. If the method is already executed, Spring uses the cache value and returns it to caller instead of calling the method again. This is a write through cache. This way, expensive methods (whether CPU or IO bound) can be executed only once for a given set of parameters and the result reused without having to actually execute the method again. The caching logic is applied transparently without any interference to the invoker.
Note the
In the above code snippet, method
It is also possible to provide multiple cache names if you have multiple caches declared in your application. For example:
In above code snippet, we provide two cache names persons and profiles. Spring framework will check in all the caches if entry is available for given method call with argument personId, if at least one cache is hit, then the associated value will be returned.
This annotation is very useful when an entire cache region needs to be cleared out. The Spring framework will ignore any key specified in this scenario as it does not apply.
To provide a different default key generator, one needs to implement the
By default, all the method arguments are used in Key generation logic. In practice not all methods have only one argument or, worse yet, the parameters are not suitable as cache keys – take for example a variation of the method above:
Here we are using just
In above code snippet, we use
This setup bootstraps ehcache library inside Spring IoC (through bean ehcache) which is then wired into the dedicated CacheManager implementation. Note the entire ehcache-specific configuration is read from the resource ehcache.xml.
Spring Framework provides support for transparently adding caching into an existing Spring application. Similar to the transaction support, the caching abstraction allows consistent use of various caching solutions with minimal impact on the code.
The cache is applied to Java methods, reducing the number of executions based on the information available. Spring checks if the given method is already executed for given set of parameters. If the method is already executed, Spring uses the cache value and returns it to caller instead of calling the method again. This is a write through cache. This way, expensive methods (whether CPU or IO bound) can be executed only once for a given set of parameters and the result reused without having to actually execute the method again. The caching logic is applied transparently without any interference to the invoker.
Adding Cache support to Spring project
In order to add Cache support to any Spring based project, one needs to declare the configuration using new Spring tag in the schema declaration.<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cache="http://www.springframework.org/schema/cache"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">
<cache:annotation-driven />
...
</beans>
Note the
cache:annotation-driven
tag in above declaration enables the caching in given Spring project.Using @Cacheable and @CacheEvict annotations
Spring 3.1 M1 provides two very useful Java annotations:@Cacheable
and @CacheEvict
which allow methods to trigger cache population or cache eviction. Let us take a closer look at each annotation:@Cacheable("persons")
public Person profile(Long personId) { ... }
In the above code snippet, method
profile
is marked cacheable using @Cacheable
annotation. Also the method is associated with a cache named “persons
“. Whenever method profile is called, the Spring framework will check if cached entry is available in persons cache and returns the same without calling profile method.It is also possible to provide multiple cache names if you have multiple caches declared in your application. For example:
@Cacheable({"persons", "profiles"})
public Person profile(Long personId) { ... }
In above code snippet, we provide two cache names persons and profiles. Spring framework will check in all the caches if entry is available for given method call with argument personId, if at least one cache is hit, then the associated value will be returned.
@CacheEvict annotation
Cache eviction is removing of any unused or stale data from the cache. Opposed to @Cacheable, annotation @CacheEvict demarcates methods that perform cache eviction, that is methods that act as triggers for removing data from the cache. Just like its sibling, @CacheEvict requires one to specify one (or multiple) caches that are affected by the action, allows a key or a condition to be specified but in addition, features an extra parameterallEntries
which indicates whether a cache-wide eviction needs to be performed rather then just an entry one (based on the key):@CacheEvict (value = "persons", allEntries=true)
public List<Person> listPersons()
This annotation is very useful when an entire cache region needs to be cleared out. The Spring framework will ignore any key specified in this scenario as it does not apply.
Using Default key
The cache is nothing but a key-value store which stores the data based on certain key. In Spring framework based caching, the method arguments of cached method acts as the source of Key generation. Every key is essentially the Hash-code of these arguments. This approach works well for objects with natural keys as long as thehashCode()
reflects that. If that is not the case then for distributed or persistent environments, the strategy needs to be changed as the objects hashCode
is not preserved. In fact, depending on the JVM implementation or running conditions, the same hashCode
can be reused for different objects, in the same VM instance.To provide a different default key generator, one needs to implement the
org.springframework.cache.KeyGenerator
interface. Once configured, the generator will be used for each declaration that does not specify its own key generation strategy. By default, all the method arguments are used in Key generation logic. In practice not all methods have only one argument or, worse yet, the parameters are not suitable as cache keys – take for example a variation of the method above:
@Cacheable(value="persons", key="personId")
public Person profile(Long personId, Long groundId) { ... }
Here we are using just
personId
in key generation ignoring groupId altogether.Understand Conditional caching
Spring framework also supports conditional caching letting user to cache certain methods based on some conditions. For example, in following code snippet we cache profiles only for those users who have profileId greater than 50:@Cacheable(value="persons", condition="personId > 50")
public Person profile(Long personId) { ... }
Currently supported libraries
There are probably hundreds of cache libraries available which can be used in your JEE project. For now the Spring framework supports following implementations:- JDK ConcurrentMap based Cache
- Ehcache based Cache
JDK ConcurrentMap based Cache
The JDK-based Cache implementation resides underorg.springframework.cache.concurrent
package. It allows one to use ConcurrentHashMap
as a backing Cache store.<!-- generic cache manager -->
<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<bean class="org.springframework.cache.concurrent.ConcurrentCacheFactoryBean" p:name="default"/>
<bean class="org.springframework.cache.concurrent.ConcurrentCacheFactoryBean" p:name="persons"/>
</set>
</property>
</bean>
In above code snippet, we use
SimpleCacheManager
class to create a CacheManager
. Note that we have created two caches in our application, one is default
and second is persons
.Ehcache based Cache
The Ehcache implementation is located underorg.springframework.cache.ehcache
package. Again, to use it, one simply needs to declare the appropriate CacheManager
:<bean id="cacheManager" class="org.springframework.cache.ehcache.EhcacheCacheManager" p:cache-manager="ehcache"/>
<!-- Ehcache library setup -->
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:config-location="ehcache.xml"/>
This setup bootstraps ehcache library inside Spring IoC (through bean ehcache) which is then wired into the dedicated CacheManager implementation. Note the entire ehcache-specific configuration is read from the resource ehcache.xml.
No comments:
Post a Comment