Declarative Caching Services for Spring
Pages: 1, 2, 3, 4

Per-bean configuration

This configuration strategy is simple and very easy to set up. Configuration of caching services is performed inside a proxy element which has a reference to a single Spring-managed bean. You must supply the id of the bean to be referred in the attribute refId . You also need to choose the methods to be intercepted to apply caching services. The elements caching and flushing specify which methods should trigger data caching and which methods should trigger cache flushing respectively. These two elements provide the attribute methodName which specifies the name of the method to intercept. These elements contain additional attributes, unique for each cache provider, that specify how caching and cache flushing should be performed by that particular cache. The following example illustrates per-bean configuration using Coherence:

<bean id="
                         customerDaoTarget"

  class="org.springmodules.cache.samples.dao.CustomerDao" />

  <!-- Properties -->

</bean>



<coherence:proxy id="customerDao" refId="
                         customerDaoTarget">

  <coherence:caching methodName="load" 

                 cacheName="customerCache" />

  <coherence:flushing methodName="update" 

                 cacheNames="customerCache" when="after" />

</coherence:proxy>
                      

Note that you should qualify every cache-related XML element with the namespace of the chosen cache provider. In our example, we set up caching services to store the return value of the method CustomerDao.load in the Coherence cache with name "customerCache" and flush the cache with the same name after the execution of the method CustomerDao.update. It is important to mention that to configure beans that have dependencies on a CustomerDao, you should use the id of the proxy element, not the id of the original bean:

<bean id="customerManager"

 class="org.springmodules.cache.samples.business.CustomerManager"/>

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

</bean>
                      

As an alternative, you can declare the bean definition inside the proxy element, which results in a more compact configuration:

<coherence:proxy id="customerDao">

  <bean

    class="org.springmodules.cache.samples.dao.CustomerDao" />

    <!-- Properties -->

  </bean>



  <coherence:caching methodName="load" 

           cacheName="customerCache" />

  <coherence:flushing methodName="update" 

           cacheNames="customerCache" when="after" />

</coherence:proxy>

Per-bean configuration offers an easy way to set up caching services. Since you need to define a beanRef element per bean, it is better to use this approach when you have an application with a small number of objects to apply caching services to.

Source-level metadata attributes

Although per-bean configuration provides a straightforward way to configure caching services, you may end up having a great amount of configuration-related XML if your application contains a fairly large number of Spring-managed beans. To simplify configuration you can "decorate" your application with source-level metadata attributes indicating which methods should be intercepted to apply caching services. Declarative caching supports Commons Attributes and J2SE 5.0 Annotations.

Commons Attributes allows you to add metadata attributes to applications using J2SE 1.4 or earlier. Because the Java compiler does not recognize this type of metadata attribute, an extra compilation process is required. Compilation of Commons Attributes metadata generates source code that must be compiled with the application's source files. There is no IDE support for Commons Attributes metadata, which means common software development practices like refactoring are not supported either. The following example illustrates the use of Commons Attributes. Note the following configuration is equivalent to the one in the previous section:

public class CustomerDao {

  

  /**

   * @@Cached(modelId="
                         cachingModel")

   */

  public Customer load(long customerId) {

    // method implementation

  }

  

  /**

   * @@FlushCache(modelId="
                         flushingModel")

   */

  public void update(Customer customer) {

    // method implementation

  }  

  // rest of class implementation

}
                      

Source-level metadata attributes are restricted to describe whether caching services should be applied, instead of describing how caching should occur. The how is described in the Spring IoC container. In our example, metadata only indicates that that the return value of the method CustomerDao.load should be cached, following the settings specified in the model with id cachingModel. The model, which is declared in the Spring IoC container, contains the cache-specific settings that describe how values are stored in the cache. The same rule applies to cache flushing. Here is the declaration of the models referenced by the metadata attributes:

<coherence:commons-attributes>

  <coherence:caching id="
                         cachingModel" 

            cacheName="customerCache" />

  <coherence:flushing id="
                         flushingModel" 

            cacheNames="customerCache" when="after" />

</coherence:commons-attributes>



<bean id="customerDao"

  class="org.springmodules.cache.samples.dao.CustomerDao" />

  <!-- Properties -->

</bean>
                      

The model with id cachingModel indicates that objects should be stored in the Coherence cache with name "customerCache." In a similar way, the model with id flushingModel indicates the same cache should be flushed after the intercepted method is executed. Any changes related to the cache provider will be performed only in the Spring IoC container without affecting cache-related metadata attributes. Such changes do not require recompilation of your Java source code. Also note that to process the cache-related metadata, you also need to declare in the Spring container an instance of the class decorated with source-level metadata (the bean customerDao in our example.)

J2SE 5.0 Annotations are a more structured format for adding metadata attributes to your applications. Because Annotations are a built-in language feature, the Java compiler identifies them as another language construct, overcoming the problems related to Commons Attributes. Configuration of caching services using J2SE 5.0 Annotations is almost identical to the configuration using Commons Attributes. In fact, it is a matter of replacing a couple of lines in the Java source code:

public class CustomerDao {

  

  @Cacheable(modelId = "
                         cachingModel")

  public Customer load(long customerId) {

    // method implementation

  }



  @CacheFlush(modelId = "
                         flushingModel")  

  public void update(Customer customer) {

    // method implementation

  }  

  // rest of class implementation

}
                      

For more information about J2SE 5.0 Annotations, refer to the JDK 1.5 documentation. Switching from Commons Attributes to J2SE 5.0 Annotations in the Spring IoC container only requires replacing the element commons-attributes with the element annotations:

<coherence:annotations>

  <coherence:caching id="
                         cachingModel" 

          cacheName="customerCache" />

  <coherence:flushing id="
                         flushingModel" 

          cacheNames="customerCache" when="after" />

</coherence:annotations>



<bean id="customerDao"

  class="org.springmodules.cache.samples.dao.CustomerDao" />

  <!-- Properties -->

</bean>
                      

Caching services using source-level metadata attributes are set up only once in the Spring IoC container. You can add as many beans as you need without requiring any extra configuration. This makes configuration with source-level metadata attributes an ideal solution when you need to apply caching services to a large number of objects.

Pages: 1, 2, 3, 4

Next Page »