Flexibility with Spring's cache abstraction

This blog post tries to demonstrate how easily you can switch the caching provider if you are using the caching abstraction from Spring framework without modifying your business logic. As an example, let's consider an expensive operation, like calling the facebook graph API to get the website of a company. This operation we could speed up with caching. If you would like to jump right ahead to the code have a look at my github profile

	@Service
	public class FacebookLookupService {
	private static final Logger LOGGER = LoggerFactory.getLogger(FacebookLookupService.class);
	private RestTemplate restTemplate;
	@Autowired
	public FacebookLookupService(RestTemplate restTemplate) {
	this.restTemplate = restTemplate;
	}
	@Cacheable("pages")
	public Page findPage(String page) {
	LOGGER.info("calling findPage with {}", page);
	return restTemplate.getForObject("http://graph.facebook.com/" + page, Page.class);
	}
	}

view raw FacebookLookupService.java hosted with ❤ by GitHub

With the @Cacheable annotation we demarcate the method which is calling an expensive remote call. On the very first time the method will be executed and the result will be put into the pages cache. Repetitive calls of the method with the same parameter will not execute the method, instead the result will be the cached value.
In this simple example the service is exposed via a Spring MVC controller as seen below, where we also measure how long it takes to call the service method.

	@RequestMapping(method = RequestMethod.GET)
	public @ResponseBody Page lookup(@RequestParam String name) {
	long start = System.currentTimeMillis();
	Page page = facebook.findPage(name);
	long elapsed = System.currentTimeMillis() - start;
	page.setLookupTime(elapsed);
	return page;
	}

view raw lookup.java hosted with ❤ by GitHub

To build and run the example, issue the following commands in a terminal:

	mvn clean install
	java -jar target/spring-caching-1.0-SNAPSHOT.jar

view raw run.sh hosted with ❤ by GitHub

The last command will start up an embedded tomcat instance using Spring Boot.
Now, in another terminal let's call the service couple of times with the same name.

	localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":90}localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":62}localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":65}localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":70}localhost:~ zoltan$

view raw client.sh hosted with ❤ by GitHub

As you can see above, the lookup took similar amount of time on each client invocation. This is because the caching is not activated, it was just declared. In order to activate caching you need a caching provider. The following code snippet configures EhCache as a caching provider for our facebook lookup service.

	@Configuration
	@EnableCaching
	@Profile("ehcache")
	public class EhCacheConfiguration {
	@Bean
	EhCacheCacheManager ehCacheCacheManager() {
	return new EhCacheCacheManager(ehCacheManagerFactoryBean().getObject());
	}
	@Bean
	EhCacheManagerFactoryBean ehCacheManagerFactoryBean() {
	EhCacheManagerFactoryBean ehCacheManagerFactoryBean = new EhCacheManagerFactoryBean();
	ehCacheManagerFactoryBean.setConfigLocation(new ClassPathResource("ehcache.xml"));
	return ehCacheManagerFactoryBean;
	}
	}

view raw EhCacheConfiguration.java hosted with ❤ by GitHub

In order to enable caching for our facebook lookup service with EhCache as caching provider, we activate the ehcache Spring profile:

java -jar target/spring-caching-1.0-SNAPSHOT.jar --spring.profiles.active=ehcache

view raw run-with-ehcache.sh hosted with ❤ by GitHub

And again in another terminal when calling the service couple of times with the same name it is visible that at first time it took more than half a second, however the subsequent calls were near instantaneous.

	localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":572}localhost:~ zoltan$ curl localhost:8080/lookup?nam=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":1}localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":0}localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":1}localhost:~ zoltan$ curl localhost:8080/lookup?name=backbase
	{"name":"Backbase","website":"http://www.backbase.com/","lookupTime":0}localhost:~ zoltan$

view raw run-caching-ehcache.sh hosted with ❤ by GitHub

Later on, we might want to scale out our service by starting more than one tomcat instance. In this case we might want to have a distributed cache, where a result cached on one node will be also available transparently on other nodes. The following code snippet contains a configuration for Hazelcast using as a distributed cache.

	@Configuration
	@EnableCaching
	@Profile("hazelcast")
	public class HazelcastConfiguration {
	@Bean
	HazelcastCacheManager hazelcastcacheManager() throws Exception {
	return new HazelcastCacheManager(hazelcastInstance());
	}
	@Bean
	HazelcastInstance hazelcastInstance() throws Exception {
	return Hazelcast.newHazelcastInstance();
	}
	}

view raw HazelcastConfiguration.java hosted with ❤ by GitHub

Run the following two commands in separate terminals, enabling caching with Hazelcast as a provider by activating the hazelcast profile.

	java -jar target/spring-caching-1.0-SNAPSHOT.jar --spring.profiles.active=hazelcast --server.port=8081
	java -jar target/spring-caching-1.0-SNAPSHOT.jar --spring.profiles.active=hazelcast --server.port=8082

view raw run-with-hazelcast.sh hosted with ❤ by GitHub

This will start up two tomcat instances one on 8081 the other on 8082 port. And as shown below we have added a distributed cache as a caching provider without changing our business logic.

	localhost:~ zoltan$ curl localhost:8082/lookup?name=google
	{"name":"Google","website":"www.google.com","lookupTime":132}localhost:~ zoltan$ curl localhost:8081/lookup?name=google
	{"name":"Google","website":"www.google.com","lookupTime":3}localhost:~ zoltan$

view raw client-distributed.sh hosted with ❤ by GitHub

In the sample project the interested reader could check out a configuration for Redis to be used as caching provider.