Often, the objects that compose applications perform the same operations with the same arguments and obtain the same results. Sometimes, these operations are costly in terms of CPU usage, or may be there is a lot of I/O going on while executing those operations.

To get better results in terms of speed and resources used, it's suggested to use a cache. We can store in it the results corresponding to the methods' invocations as key-value pairs: method and arguments as key and return object as value.

Once you decide to use a cache you're just halfway. In fact, you must decide which part of the application is going to use the cache. Let's think about a web application backed by a database. Such a web application usually involves Data Access Objects (DAOs), which access the relational database. Such objects are usually a bottleneck in the application as there is a lot of I/O going on. In other words, a cache can be used there.

The cache can also be used by the business layer that has already aggregated and elaborated data retrieved from repositories, or it can be used by the presentation layer putting formatted presentation templates in the cache, or even by the authentication system that keeps roles according to an authenticated username.

There are almost no limits as to how you can optimize an application and make it faster. The only price you pay is having RAM to dedicate the objects that are to be kept in memory, besides paying attention to the rules on how to manage the life of the objects in cache.

After these preliminary remarks, using a cache could seem common and obvious. A cache essentially acts as a hash into which key-value pairs are put. The keys are used to retrieve objects from the cache. Caching usually has confi guration parameters that allow you to change its behavior.

Now let's have a look at an example with ehcache (http://ehcache.sourceforge. net). First of all let's confi gure it with the name methodCache so that we have at the most 1000 objects. The objects are inactive for a maximum of fi ve minutes, with a maximum life of 10 minutes. If the objects count is over 1000, ehcache saves them on the fi lesystem, in java.io.tmpdir.

<ehcache>

…

<diskStore path="java.io.tmpdir"/>

….

<defaultCache

maxElementsInMemory="10000"

eternal="false"

timeToIdleSeconds="120"

timeToLiveSeconds="120"

overflowToDisk="true"

diskPersistent="false"

diskExpiryThreadIntervalSeconds="120"

/>

…

<cache name="methodCache"

maxElementsInMemory="1000"

eternal="false"

overflowToDisk="false"

timeToIdleSeconds="300"

timeToLiveSeconds="600"

/>

</ehcache>

Now let's create a CacheAspect. Let's defi ne the cacheObject to which the ProceedingJoinPoint is passed. Let's recover an unambiguous key from the ProceedingJoinPoint with the method getCacheKey. We will use this key to put the objects into the cache and to recover them.

Once we have obtained the key, we ask to cache the Element with the instruction cache.get(cacheKey). The Element has to be evaluated because it may be null if the cache didn't fi nd an Element with the passed cacheKey.

If the Element is null, advice invokes the method proceed(), and puts in the cache the Element with the key corresponding to the invocation. Otherwise, if the Element recovered from the cache is not null, the method isn't invoked on the target class, and the value taken from the cache is returned to the caller.

package org.springaop.chapter.five.cache;

import it.springaop.utils.Constants;

import net.sf.ehcache.Cache;

import net.sf.ehcache.Element;

import org.apache.log4j.Logger;

import org.aspectj.lang.ProceedingJoinPoint;

public class CacheAspect {

public Object cacheObject(ProceedingJoinPoint pjp) throws Throwable

{

Object result;

String cacheKey = getCacheKey(pjp);

Element element = (Element) cache.get(cacheKey);

logger.info(new StringBuilder("CacheAspect invoke:").append("n get:") .append(cacheKey).append(" value:").append(element). toString());

if (element == null) {

result = pjp.proceed();

element = new Element(cacheKey, result);

cache.put(element);

logger.info(new StringBuilder("n put:").append(cacheKey). append( " value:").append(result).toString());

}

return element.getValue();

}

public void flush() {

cache.flush();

}

private String getCacheKey(ProceedingJoinPoint pjp) {

String targetName = pjp.getTarget().getClass().getSimpleName();

String methodName = pjp.getSignature().getName();

Object[] arguments = pjp.getArgs();

StringBuilder sb = new StringBuilder();

sb.append(targetName).append(".").append(methodName);

if ((arguments != null) && (arguments.length != 0)) {

for (int i = 0; i < arguments.length; i++) {

sb.append(".").append(arguments[i]);

}

}

return sb.toString();

}

public void setCache(Cache cache) {

this.cache = cache;

}

private Cache cache;

private Logger logger = Logger.getLogger(Constants.LOG_NAME);

}

Here is applicationContext.xml :

<beans xmlns=»http://www.springframework.org/schema/beans»

xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»

xmlns:aop=»http://www.springframework.org/schema/aop»

xsi:schemaLocation=»http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-2.5.xsd»> …

<bean id="rockerCacheAspect" class="org.springaop.chapter.five. cache.CacheAspect" >

<property name="cache">

<bean id="bandCache" parent="cache">

<property name="cacheName" value="methodCache" />

</bean>

</property>

</bean>

<!-- CACHE config -->

<bean id="cache" abstract="true" class="org.springframework.cache.ehcache.EhCacheFactoryBean">

<property name="cacheManager" ref="cacheManager" />

</bean>,

<bean id="cacheManager"

class="org.springframework.cache.ehcache.

EhCacheManagerFactoryBean">

<property name="configLocation" value="classpath:org/springaop/

chapter/five/cache/ehcache.xml" />

</bean>

…

</beans>

The idea about the caching aspect is to avoid repetition in our code base and have a consistent strategy for identifying objects (for example using the hash code of an object) so as to prevent objects from ending up in the cache twice.

Employing an around advice, we can use the cache to make the method invocations return the cached result of a previous invocation of the same method in a totally transparent way. In fact, to the methods of the classes defi ned in the interception rules in pointcuts will be given back the return values drawn from the cache or, if these are not present, they will be invoked and inserted in the cache. In this way, the classes and methods don't have any knowledge of obtaining values retrieved from the cache.