In this article we’ll have a look at the new Spring 3 feature: caching by annotation.<\/p>\n
<\/p>\n
Caching is an important feature for all applications needing high performance. Many open-source frameworks are available: EhCache<\/strong>, JBoss Cache<\/strong>, OSCache<\/strong>, Open Terracota<\/strong> …<\/p>\n Their integration with the application is sometimes easy sometimes more complex, depending on the desired features and use (distributed cache ? cache JMX management …)<\/p>\n Spring 3 introduces a new abstraction layer for caching services. The idea is to provide a set of common features, mainly annotations, to activate and manage the caches.<\/p>\n Since it is only an abstract layer, Spring 3 caching still need a concrete implementation to work. The entry point for cache implementation is the CacheManage<\/strong>r interface. By default 2 concrete implementation of CacheManager<\/strong> are provided: <\/p>\n <\/p>\n For this example we’ll use EhCache as cache implementation.<\/p>\n First you need to import the Spring cache namespace and add the &th;cache:annotation-driver> tag.<\/p>\n Then you need to declare the cacheManager bean and implementation instance (or factory bean)<\/p>\n First we declare the EhCacheCacheManager<\/strong> as default cache manager. Then we inject the EhCacheManagerFactoryBean<\/strong> so it can retrieve an instance of EhCache class.<\/p>\n Please notice the very confusing naming. The EhCacheCacheManager<\/strong> instance is given the id “cacheManager<\/strong>” as per Spring convention but it also has a cacheManager property<\/strong>. This property is indeed an instance of net.sf.ehcache.CacheManager<\/strong>, different from the org.springframework.cache.CacheManager<\/strong> interface.<\/p>\n Last but not least, you can specify the config file for ehcache with the property configLocation<\/strong> of EhCacheManagerFactoryBean<\/strong>. If not declared it will default to “ehcache.xml<\/strong>”<\/p>\n <\/p>\n By default Spring proposes several annotations to manage your caches:<\/p>\n And that’s pretty much. But don’t be fooled by their apparent simplicity, they offer a lot of possibilities to fine tune your caching.<\/p>\n When annotating a method with @Cacheable<\/strong>, its returned value<\/strong> will be put into the cache provided it meets some condition (if any). Consequently it does not make sense to annotate a void<\/strong> method.<\/p>\n So what can be put in cache ?<\/strong> Pretty much anything, an Object, a collection (List, Map, Set, Array)…<\/p>\n When is the cache activated ?<\/strong> All subsequent calls on the same method with the same arguments or cache key (we’ll see it later) will trigger the cache. Instead of executing the method, the cache is scanned to check whether a matching entry can be found, if yes then it is returned. Otherwise the method is really executed and its result put into the cache.<\/p>\n Below is the pseudo-code:<\/p>\n So what is the cache key and why do we need to use args hashCode<\/strong> ? We’ll see it shortly. First the @Cacheable<\/strong> annotation offers the following attributes:<\/p>\n Example:<\/p>\n In the above example<\/p>\n Please notice that for the key and condition attributes, we are using SpEL<\/a> to process the method arguments.<\/p>\n This is very convenient because the SpEL<\/strong> expression language is extremely powerfull. For example, if the UserSearchVO<\/strong> has an attribute searchType<\/em> of enum type, we can do the following:<\/p>\n In this case the cache is triggered only when the search is of type CLASSIC. <\/p>\n Note that we use ==<\/strong> instead of equals()<\/em> to check for the searchType<\/em>. Since the attribute searchType<\/em> is an enum<\/strong>, we want to check object identity (same reference)<\/strong> with == rather than object equality (same value)<\/strong> with equals()<\/em>.\n<\/p><\/blockquote>\n Another simple example:<\/p>\n In this example, we declare more than one cache (“user-cache1”<\/strong>,“user-cache2”<\/strong>) and no key<\/strong> information. <\/p>\n By default if no cache key is provided Spring will compute a hash code of all method arguments (here it is login<\/em> & name<\/em>) and use it as a key for cache lookup. If your method arguments are not of primitive type and you want them to be used as cache key, you should redefine properly the hashCode() method<\/strong>.<\/p>\n Last but not least, Spring will scan each cache for key lookup, if an entry is found in any declared cache, it will be returned, subsequent caches are skipped<\/strong>. If all caches are scanned and no entry is found, the method will be executed and the result added to all the declared caches.<\/p>\n <\/p>\n The @CacheEvict<\/strong> is used to trigger explicit cache eviction<\/strong>. By default most of caching frameworks expire the cache data after some defined duration. The @CacheEvict<\/strong> annotation is usefull when you want to control explicit cache eviction upon some method calls.<\/p>\n The above code is quite self-explanatory. The @CacheEvict<\/strong> annotation exposes the following attributes:<\/p>\n Obviously the key<\/strong> and allEntries<\/strong> attributes are mutually exclusive.<\/p>\n <\/p>\n The @CachePut<\/strong> annotation allows you to “update” a cache entry. This is very similar to @Cacheable<\/strong> but for entry update. The @CachePut<\/strong> annotation has exactly the same attributes than @Cacheable<\/strong>.<\/p>\n In the case of @CachePut<\/strong>, the method is always executed<\/strong> and its returned result is put into the cache, using the provided key (or arguments hash), replacing the old entry if necessary.<\/p>\n The only case where the method is not executed is when you provide an optional @CachePut<\/strong> condition<\/strong> and the condition is not met. Let’s suppose than we have an application with 2 cache regions: “user-cache” and “user-details-cache”.<\/p>\n It is possible to trigger the eviction from both caches with the same key:<\/p>\n In this particular example, it’s working very well because we access both caches with the same key. What if we want to evict from those caches with different keys ?<\/p>\n It’s simply not possible because Java does not allow you to have more than one type of annotation on the same method.<\/p>\n For this kind of use case, Spring provides a generic @Caching<\/strong> annotation. This annotation simply allows you to group caching annotations of same type like @Cacheable<\/strong>, @CacheEvict<\/strong> or @CachePut<\/strong>.<\/p>\n With this said, our example becomes:<\/p>\n And you’re done!<\/p>\n Of course if you try to mix caching annotation of different type in the same @Caching<\/strong>, needless to say that you are running into big trouble…<\/p>\n <\/p>\n So far the caching abstraction infrastructure proposed by Spring is very convenient. However, for having used it in a real project, I’ve spotted 1 pain point : object mutability issues, thought this point is not Spring’s specific but common to all caching frameworks.<\/p>\n Indeed when you get an instance of User after calling findUserByLogin(String login)<\/em>, this instance may come from the cache directly.<\/p>\n If you are modifying this User<\/strong> instance (changing an user property for example), you are indeed modifying the object which is in the cache directly !!!<\/p>\n The immediate consequence is that on the same server, if another client looks for the same user, the cache will give him the same User<\/strong> instance that has been modified earlier…<\/p>\n There are 2 solutions for this issue. <\/p>\n Fortunately, latest EHCache<\/strong> versions provide a very usefull feature: copyOnRead<\/strong>.<\/p>\n With this flag turned on, EHCache<\/strong> will return you a deep copy<\/strong> of the object instance that is in the cache, not the instance itself. So mutability issue is solved.<\/p>\n Of course there is no free lunch, this convenient feature comes with its counterparts, the cost of serialization\/deserialization<\/strong> because the default implementation is plain Java object serialization.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" In this article we’ll have a look at the new Spring 3 feature: caching by annotation.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[21,14],"tags":[],"_links":{"self":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1188"}],"collection":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1188"}],"version-history":[{"count":0,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1188\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
II Configuration<\/h1>\n
\n<cache:annotation-driven cache-manager="cacheManager" mode="proxy" order="1" \/>\n<\/pre>\n
\n
\n<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager">\n\t<property name="cacheManager" ref="ehcache"\/>\n<\/bean>\n\n<!-- Ehcache library setup -->\n<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">\n\t<property name="configLocation" value="classpath:ehcache.xml"\/>\n<\/bean>\n<\/pre>\n
III Cache annotations<\/h1>\n
\n
A @Cacheable<\/h3>\n
\n
\n
\n
\n
\n@Cacheable(value = "user-cache", key="#userSearchVO.name", condition="#supportUser == false")\npublic User findUser(UserSearchVO userSearchVO, boolean supportUser)\n{\n\tUser foundUser = null;\n\t...\n\t...\n\t...\n\treturn foundUser;\n}\n<\/pre>\n\n
\n@Cacheable(value = "user-cache", key="#userSearchVO.name", condition="#userSearchVO.searchType == ${T(com.doan.spring.cache.SearchType).CLASSIC")\npublic User findUser(UserSearchVO userSearchVO, boolean supportUser)\n{\n\tUser foundUser = null;\n\t...\n\t...\n\t...\n\treturn foundUser;\n}\n\npublic enum SearchType\n{\n\tCLASSIC,\n\tADVANCED,\n\tSUPPORT\n}\n<\/pre>\n\n@Cacheable(value = {"user-cache1","user-cache2"})\npublic User findUserByLoginAndName(String login, String name)\n{\n\tUser foundUser = null;\n\t...\n\t...\n\t...\n\treturn foundUser;\n}\n<\/pre>\nB @CacheEvict<\/h3>\n
\n@CacheEvict(value = "user-cache", key = "#user.login")\npublic void updateUser(User user)\n{\n\t...\n\t...\n}\n<\/pre>\n\n
C @CachePut<\/h3>\n
\n@CachePut(value = "user-cache", key = "#user.login")\npublic User updateUserName(User user,String newName)\n{\n\t...\n\t...\n\tuser.setName(newName);\n\t...\n\t...\n\treturn user;\n}\n<\/pre>\n
\n <\/p>\nIV Multiple caching policies<\/h1>\n
\n@Cacheable(value = "user-cache", key="#login")\npublic User findUserByLogin(String login)\n{\n\t...\n\t...\n\treturn foundUser;\n}\n...\n...\n\n@Cacheable(value = "user-details-cache", key="#login")\npublic UserDetails findUserDetailsByLogin(String login)\n{\n\t...\n\t...\n\treturn userDetails;\n}\n<\/pre>\n\n@CacheEvict(value = \n{\n\t"user-cache",\n\t"user-details-cache"\n}, key="#login")\npublic void updateUserDetails(String login, UserDetails newUserDetails)\n{\n\t...\n\t...\n}\n<\/pre>\n\n@CacheEvict(value = "user-cache", key="#login")\n@CacheEvict(value = "user-details-cache", key="#newUserDetails.id")\npublic void updateUserDetails(String login, UserDetails newUserDetails)\n{\n\t...\n\t...\n}\n<\/pre>\n\n@Caching(evict = {\n\t@CacheEvict(value = "user-cache", key="#login"),\n\t@CacheEvict(value = "user-details-cache", key="#newUserDetails.id")\n})\npublic void updateUserDetails(String login, UserDetails newUserDetails)\n{\n\t...\n\t...\n}\n<\/pre>\nV Object mutability gotcha<\/h1>\n
\n
\n<cache name="user-cache"\n\t...\n\teternal="false"\n\ttimeToIdleSeconds="10"\n\ttimeToLiveSeconds="1800"\n\toverflowToDisk="false"\n\tcopyOnRead="true"\n>\n<\/cache>\n<\/pre>\n