《디자인 패턴》(Design Patterns, ISBN 0201633612)은 소프트웨어 설계에 있어 공통된 문제들에 대한 표준적인 해법과 작명법을 제안한 책이다. 이 분야의 사인방(Gang of Four, 줄여 GoF)으로 불리는 에리히 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)가 같이 썼고, 한국어 판은 김정아의 번역으로 피어슨 에듀케이션 코리아를 통해 출판되었다.

책의 첫 번째 반절은 다양한 디자인 패턴의 정의에 할애하고 있고, 나머지 반절은 실제적으로 유용한 디자인 패턴들을 나열하고 있다. 책의 예제들은 객체지향적인 언어인 C++과 스몰토크로 제시되고 있다. 다음은 책에서 언급되고 있는 패턴의 리스트이다.

생성 패턴(Creational Patterns)[편집]

• 추상 팩토리 패턴: 동일한 주제의 다른 팩토리를 묶어 준다.
• 빌더 패턴: 생성(construction)과 표기(representation)를 분리해 복잡한 객체를 생성한다
• 팩토리 메서드 패턴: 생성할 객체의 클래스를 국한하지 않고 객체를 생성한다.
• 프로토타입 패턴: 기존 객체를 복제함으로써 객체를 생성한다.
• 싱글턴 패턴: 한 클래스에 한 객체만 존재하도록 제한한다.

구조 패턴(Structural Patterns)[편집]

• 어댑터 패턴: 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌운다.
• 브리지 패턴: 추상화와 구현을 분리해 둘을 각각 따로 발전시킬 수 있다.
• 합성 패턴: 0개, 1개 혹은 그 이상의 객체를 묶어 하나의 객체로 이용할 수 있다.
• 데코레이터 패턴: 기존 객체의 매서드에 새로운 행동을 추가하거나 오버라이드 할 수 있다.
• 파사드 패턴: 많은 분량의 코드에 접근할 수 있는 단순한 인터페이스를 제공한다.
• 플라이웨이트 패턴: 다수의 유사한 객체를 생성·조작하는 비용을 절감할 수 있다.
• 프록시 패턴: 접근 조절, 비용 절감, 복잡도 감소를 위해 접근이 힘든 객체에 대한 대역을 제공한다.

행위 패턴(Behavioral Patterns)[편집]

• 책임연쇄 패턴(Chain of responsibility): 일련의 처리 객체들에 명령을 대행
• 커맨드 패턴: 작업(action)과 매개변수를 묶어놓은 객체를 생성
• 해석자 패턴 (Interpreter pattern): 특정 언어를 구현
• 반복자 패턴 (Iterator pattern): 내부 구조를 드러내지 않고 객체의 구성요소들을 순차적으로 접근
• 중개자 패턴 (Mediator pattern): 둘 이상의 클래스가 가지고 있는 매서드 들을 알고 있는 유일한 클래스로 클래스들을 느슨하게 연결
• 메멘토 패턴 (Memento pattern): 객체를 이전 상태로 복구하는 능력 제공
• 옵저버 패턴: 옵저버 객체들이 이벤트를 볼 수 있게 하는 패턴
• 상태 패턴 (State pattern)
• 전략 패턴 (Strategy pattern)
• 템플릿 메서드 패턴 (Template method pattern)
• 방문자 패턴 (Visitor pattern)

출처 - http://ko.wikipedia.org/wiki/%EB%94%94%EC%9E%90%EC%9D%B8_%ED%8C%A8%ED%84%B4_(%EC%B1%85)

Evaluate after the method has been called

Hooray, as of Spring 3.2 the framework allows for this using Spring SPEL and unless. Note from the java doc surrounding Cacheable:

http://static.springsource.org/spring/docs/3.2.x/javadoc-api/org/springframework/cache/annotation/Cacheable.html

public abstract String unless

Spring Expression Language (SpEL) attribute used to veto method caching.

Unlike condition(), this expression is evaluated after the method has been called and can therefore refer to the result. Default is "", meaning that caching is never vetoed.

The important aspect is that unless is evaluated after the method has been called. This makes perfect sense because the method will never get executed if the key is already in the cache.

So in the above example you would simply annotate as follows (#result is available to test the return value of a method):

@Cacheable(value="defaultCache", key="#pk", unless="#result == null")
public Person findPerson(int pk) {
   return getSession.getPerson(pk);
}

I would imagine this condition arises from the use of pluggable cache implementations such as Ehcache which allows caching of nulls. Depending on your use case scenario this may or may not be desirable.

출처 - http://stackoverflow.com/questions/12113725/how-do-i-tell-spring-cache-not-to-cache-null-value-in-cacheable-annotation

Using Spring and Ehcache

Introduction

Ehcache has had excellent Spring integration for many years. This page demonstrates two new ways of using Ehcache with Spring.

Spring 3.1

Spring Framework 3.1 added a new generic cache abstraction for transparently applying caching to Spring applications. It adds caching support for classes and methods using two annotations:

@Cacheable

Cache a method call. In the following example, the value is the return type, a Manual. The key is extracted from the ISBN argument using the id.

@Cacheable(value="manual", key="#isbn.id")
public Manual findManual(ISBN isbn, boolean checkWarehouse)

@CacheEvict

Clears the cache when called.

@CacheEvict(value = "manuals", allEntries=true)
public void loadManuals(InputStream batch)

Spring 3.1 includes an Ehcache implementation. See the Spring 3.1 JavaDoc.

It also does much more with SpEL expressions. See http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/ for an excellent blog post covering this material in more detail.

Spring 2.5 - 3.1: Ehcache Annotations For Spring

This open source, led by Eric Dalquist, predates the Spring 3.1 project. You can use it with earlier versions of Spring or you can use it with 3.1.

@Cacheable

As with Spring 3.1 it uses an @Cacheable annotation to cache a method. In this example calls to findMessage are stored in a cache named "messageCache". The values are of type Message. The id for each entry is the id argument given.

@Cacheable(cacheName = "messageCache")
public Message findMessage(long id)

@TriggersRemove

And for cache invalidation, there is the @TriggersRemove annotation. In this example, cache.removeAll() is called after the method is invoked.

@TriggersRemove(cacheName = "messagesCache",
when = When.AFTER_METHOD_INVOCATION, removeAll = true)
public void addMessage(Message message)

See http://blog.goyello.com/2010/07/29/quick-start-with-ehcache-annotations-for-spring/ for a blog post explaining its use and providing further links.

출처 - http://ehcache.org/documentation/2.5/integrations/spring

SPRING 3.1 M1: CACHE ABSTRACTION

Posted on February 23rd, 2011 by Costin Leau in 3.1, Containers, Data Access, Java, Open Source, Spring.

One of the major features added in Spring Framework 3.1 M1 is the generic cache abstraction for transparently applying caching to Spring applications. Just like the transaction support, the caching abstraction allows consistent use of various caching solutions with minimal impact on the code.

Purpose

Caches are in general used to improve application performance by transparently serving frequently accessed data in a faster fashion such as serving data from local memory rather than from the network. Many of you have already used caching, whether knowingly or not: most ORM/JPA frameworks provide dedicated caching functionality (also known as the 2nd-level cache). Spring 3.1 M1 however introduces a generic cache mechanism that can be applied to any Java class, method or library: one can use it in conjunction with an existing caching infrastructure, to add caching to APIs without such support (for example JDBC) or simply to improve the performance of a slow, time-consuming and resource-hungry method.

Meet @Cacheable, @CacheEvict and SpEL

Let us see what it takes to cache an arbitrary method:

@Cacheable("books")

public Book findBook(ISBN isbn) {...}

By marking the method with the @Cacheable annotation, we tell the container that thefindBook method is backed by the cache entry books. That is each time the method is called, a cache lookup is performed using as key the method parameters (in this case theisbn argument). If a value is found, it will be returned and the method execution skipped. However, if the key is not found, the method is executed as usual and its result stored in the cache so the next time the method is invoked, the result can be returned without actually executing the (expensive or slow) method.

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:

public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

In such cases, one can use Spring 3 Spring Expression Language or SpEL to cherry pick the proper arguments, navigate the object tree

// use property 'rawNumber' on isbn argument as key

@Cacheable(value="book", key="#isbn.rawNumber")

public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

or compute the key on the fly, even call arbitrary methods without having to write any code:

// get the key by calling someType#hash(isbn)

@Cacheable(value="book", key="T(someType).hash(#isbn)")

public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

Additionally, one can specify when or if the caching should occur: whether the cache should be inspected or completely disregarded and the method executed normally. It's up to the developer to decide what the criteria is: can be anything from the key size or type to the time of day or result of arbitrary methods: SpEL supports it all:

// cache only names shorter then 32 chars

@Cacheable(value="book", condition="#name.length < 32")

public Book findBook(String name)

// do not cache on weekends

@Cacheable(value="book", condition="!T(TimeUtils).isWeekend()")

public Book findBook(String name)

The cache abstraction also supports eviction of cache entries or of an entire cache through the @CacheEvict annotation. To evict a cache once it becomes invalid (for example because the cached data has been updated) one can use the following:

// evict all cache entries

@CacheEvict(value = "books", allEntries=true)

public void loadBooks(InputStream batch)

Once the annotations are in place, one can simply "enable" the caching functionality with one line (or three if you count 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>

Just like the rest of the annotation-driven element, the cache one uses defaults in its simplest form but can be used to pick between proxy and byte-code weaving of cached classes or to wire in the desired cache implementation.

Declaring a cache implementation

So far, we discussed the declarative aspect of the caching abstraction: how to add and remove data from the cache based on your POJOs. But what are the backing cache implementations that one can use?
Out of the box, Spring provides integration with ehcache and JDK ConcurrentHashMapgreat for small, non-distributed environments or testing:

<!-- 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="books"/>

</set>

</property>

</bean>

What about [xx] library – when will it be supported ?

For the moment we do not plan to support other caching libraries inside Spring Framework simply because of the sheer number of options out there, the dependency impact (many are bigger in size than the cache abstraction), and the maintenance and licensing issues. To plug-in a custom cache provider, we encourage developers to look at the caching SPIpackage and its two interfaces: CacheManager and Cache. Besides the implementations available out of the box, one can look at the GemFire implementation, scheduled for the next major release version of Spring GemFire.

How does the caching abstraction compare to other caches (e.g. JPA 2nd-level cache) ?

In general, the two caching mechanisms can happily coexist as long as the developer pays attention to any domain overlap. Taking the example of the JPA 2nd-level cache, one can used it for data access through JPA while using Spring caching for the web-tier or remote service calls. One can go a step further by reusing the backed cache between the two mechanisms if that applies.

Summary

I hope you enjoyed this quick introductory entry to the new caching feature in Spring 3.1. For more information, please see the relevant reference documentation chapter and the SPIjavadoc. And do let us know what you think – we are interested in your feedback! You can reach us through the forum, blog post comments, our issue tracker or yours truly on Twitter.

SIMILAR POSTS

• Transactions, Caching and AOP: understanding proxy usage in Spring
• XPath Support in Spring Web Services
• Spring Framework 3.1 M2 released
• Spring Framework 3.1 goes GA
• Spring Framework 3.1 RC1 released

출처 - http://blog.springsource.com/2011/02/23/spring-3-1-m1-caching/

Quick start with method caching using Spring 3.1 and Ehcache

A while ago I wrote about method caching in Java using Ehcache Annotations for Spring. However, Spring 3.1 release, among many enhancements, brings native support for method caching with so-called cache abstraction. The main usage scenario of cache abstraction is to reduce the number of expensive executions and/or slow methods returning the same result for given parameters. The usage of Spring cache abstraction consists of two aspects: cache declaration and configuration. Spring provides many ways for declaring and configuring caching in an application: annotation-based, XML-based or mixed. In this article I will create an application that utilizes cache using Java-based approach. The example used in this article is a bit modified project taken from the original article.

Create a new web project

    mvn archetype:generate
        -DarchetypeGroupId=com.github.spring-mvc-archetypes
        -DarchetypeArtifactId=spring-mvc-quickstart
        -DarchetypeVersion=1.0.0-SNAPSHOT
        -DgroupId=my.groupid
        -DartifactId=my-artifactId
        -Dversion=version

Ehcache dependency

Cache configuration

Cache declaration

• use cache with name messageCache for caching messages for invocations offindByRecipient(String)
• use cache with name messagesCache for caching messages for invocations of findAll()
• remove all elements from both caches after the invocation of createMessage(Message)

INFO : org.springframework.cache.ehcache.EhCacheManagerFactoryBean - Initializing EHCache CacheManager
DEBUG: org.springframework.cache.annotation.AnnotationCacheOperationSource - Adding cacheable method 'findByRecipient' with attribute: [CacheableOperation[public java.util.List com.github.springmvcdemos.cachedemo.domain.MessageRepository.findByRecipient(java.lang.String)] caches=[messageCache] | condition='' | key='']
DEBUG: org.springframework.cache.annotation.AnnotationCacheOperationSource - Adding cacheable method 'createMessage' with attribute: [CacheEvictOperation[public com.github.springmvcdemos.cachedemo.domain.Message com.github.springmvcdemos.cachedemo.domain.MessageRepository.createMessage(com.github.springmvcdemos.cachedemo.domain.Message)] caches=[messageCache, messagesCache] | condition='' | key='',true,false]
DEBUG: org.springframework.cache.annotation.AnnotationCacheOperationSource - Adding cacheable method 'findAll' with attribute: [CacheableOperation[public java.util.List com.github.springmvcdemos.cachedemo.domain.MessageRepository.findAll()] caches=[messagesCache] | condition='' | key='']

Hibernate: select message0_.id as id0_, message0_.body as body0_, message0_.recipient as recipient0_ from Message message0_ where message0_.recipient=?

Summary

References

• Quick start with Ehcache Annotations for Spring – the original article describing method caching using ehcache annotations for Spring project.
• Spring reference documentation

출처 - http://blog.goyello.com/2012/01/20/quick-start-with-methods-caching-using-spring-3-1-and-ehcache/

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.

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.

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 annotation

This annotation mark a method cacheable. Thus the result from this method call will be stored into the cache on subsequent invocations with same arguments.

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:

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 parameter allEntries which indicates whether a cache-wide eviction needs to be performed rather then just an entry one (based on the key):

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 the hashCode() 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 hashCodecan be reused for different objects, in the same VM instance.

To provide a different default key generator, one needs to implement theorg.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:

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:

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:

1. JDK ConcurrentMap based Cache
2. Ehcache based Cache

JDK ConcurrentMap based Cache

The JDK-based Cache implementation resides under org.springframework.cache.concurrent package. It allows one to use ConcurrentHashMap as a backing Cache store.

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 under org.springframework.cache.ehcache package. Again, to use it, one simply needs to declare the appropriate CacheManager:

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.

References

• Spring framework 3.1 M1 release
• Spring Cache documentation

출처 - http://viralpatel.net/blogs/cache-support-spring-3-1-m1/

TUESDAY, OCTOBER 4, 2011

출처 - http://eiconsulting.blogspot.kr/2011/10/ehcache-implementation-in-spring.html

Cache abstraction in Spring 3

In this article we’ll have a look at the new Spring 3 feature: caching by annotation.

I Cache abstraction layer

Caching is an important feature for all applications needing high performance. Many open-source frameworks are available: EhCache, JBoss Cache, OSCache, Open Terracota …

Their integration with the application is sometimes easy sometimes more complex, depending on the desired features and use (distributed cache ? cache JMX management …)

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.

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 CacheManager interface. By default 2 concrete implementation of CacheManager are provided:

• EhCacheCacheManager: default implementation for EhCache
• ConcurrentMapCacheManager: default implementation using Java ConcurrentHashMap as cache store

II Configuration

For this example we’ll use EhCache as cache implementation.

First you need to import the Spring cache namespace and add the &th;cache:annotation-driver> tag.

• cache-manager: id or name of the bean implementing the CacheManager interface. Can be omitted because by convention Spring will look for any bean with the name “cacheManager“
• mode: proxy or aspectj. “proxy” will use Spring AOP framework to proxy any class having a caching annotation (see below). “aspectj” will rely on AspectJ aspect for cache management
• order: optional. If you have more than one aspect declared on the same method, it can be useful to specify the order in which they execute

Then you need to declare the cacheManager bean and implementation instance (or factory bean)

First we declare the EhCacheCacheManager as default cache manager. Then we inject theEhCacheManagerFactoryBean so it can retrieve an instance of EhCache class.

Please notice the very confusing naming. The EhCacheCacheManager instance is given the id “cacheManager” as per Spring convention but it also has a cacheManager property. This property is indeed an instance ofnet.sf.ehcache.CacheManager, different from the org.springframework.cache.CacheManager interface.

Last but not least, you can specify the config file for ehcache with the property configLocation ofEhCacheManagerFactoryBean. If not declared it will default to “ehcache.xml“

III Cache annotations

By default Spring proposes several annotations to manage your caches:

• @Cacheable: put the method returned value(s) into the cache
• @CacheEvict: remove an entry from the cache
• @CachePut: force a cache entry to be updated

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.

A @Cacheable

When annotating a method with @Cacheable, its returned value will be put into the cache provided it meets some condition (if any). Consequently it does not make sense to annotate a void method.

So what can be put in cache ? Pretty much anything, an Object, a collection (List, Map, Set, Array)…

When is the cache activated ? 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.

Below is the pseudo-code:

• Method is called with arguments args
• Use the args hashCode or extract the cache key from the args to look for an entry in the cache
• If a corresponding entry is found
  • Return the cached entry
• Else
  • Execute really the method
  • Put the method returned value into the cache using the args hashCode of extracted cache key

So what is the cache key and why do we need to use args hashCode ? We’ll see it shortly. First the @Cacheableannotation offers the following attributes:

• value: mandatory, the name of the cache to work on
• key: optional, the key used to store and fetch data from the cache
• condition: optional, specifies the condition to verify before caching an item

Example:

In the above example

• value = “user-cache” indicates the name of the cache in which entries are stored
• key=”#searchVO.name” defines the key to lookup into the cache. Here it is the name property of theUserSearchVO object
• condition=”#supportUser == false” provides the condition to trigger the cache. The cache lookup and the method result caching are triggered only when the supportUser flag is set to false

Please notice that for the key and condition attributes, we are using SpEL to process the method arguments.

This is very convenient because the SpEL expression language is extremely powerfull. For example, if theUserSearchVO has an attribute searchType of enum type, we can do the following:

In this case the cache is triggered only when the search is of type CLASSIC.

Note that we use == instead of equals() to check for the searchType. Since the attribute searchTypeis an enum, we want to check object identity (same reference) with == rather than object equality (same value) with equals().

Another simple example:

In this example, we declare more than one cache (“user-cache1″,“user-cache2″) and no key information.

By default if no cache key is provided Spring will compute a hash code of all method arguments (here it is login &name) 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.

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. If all caches are scanned and no entry is found, the method will be executed and the result added to all the declared caches.

B @CacheEvict

The @CacheEvict is used to trigger explicit cache eviction. By default most of caching frameworks expire the cache data after some defined duration. The @CacheEvict annotation is usefull when you want to control explicit cache eviction upon some method calls.

The above code is quite self-explanatory. The @CacheEvict annotation exposes the following attributes:

• value: mandatory, the name of the cache to evict entry
• key: optional, the key used to lookup data from the cache
• condition: optional, specifies the condition to verify before evicting a cache entry
• allEntries: optional, indicates that all entries from the cache should be removed
• beforeInvocation: optional, indicates whether the cache evict should be done before or after method call

Obviously the key and allEntries attributes are mutually exclusive.

C @CachePut

The @CachePut annotation allows you to “update” a cache entry. This is very similar to @Cacheable but for entry update. The @CachePut annotation has exactly the same attributes than @Cacheable.

In the case of @CachePut, the method is always executed and its returned result is put into the cache, using the provided key (or arguments hash), replacing the old entry if necessary.

The only case where the method is not executed is when you provide an optional @CachePut condition and the condition is not met.
 

IV Multiple caching policies

Let’s suppose than we have an application with 2 cache regions: “user-cache” and “user-details-cache”.

It is possible to trigger the eviction from both caches with the same key:

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 ?

It’s simply not possible because Java does not allow you to have more than one type of annotation on the same method.

For this kind of use case, Spring provides a generic @Caching annotation. This annotation simply allows you to group caching annotations of same type like @Cacheable, @CacheEvict or @CachePut.

With this said, our example becomes:

And you’re done!

Of course if you try to mix caching annotation of different type in the same @Caching, needless to say that you are running into big trouble…

V Object mutability gotcha

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.

Indeed when you get an instance of User after calling findUserByLogin(String login), this instance may come from the cache directly.

If you are modifying this User instance (changing an user property for example), you are indeed modifying the object which is in the cache directly !!!

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 instance that has been modified earlier…

There are 2 solutions for this issue.

1. The first idea is to use objects returned from cache as read-only but this rule cannot be enforced easily. Suppose that you put @Cacheable annotation on a Repository or DAO method, the developper that calls this method from Service layer may not be aware that he’s getting a cached instance and may modify it.
2. The second fix is to perform a deep copy of the returned object. But again, implementing deep copy is not an easy task (as I mentioned in my article about Object Immutablity) and the deep copy should be done by thecaller (Service layer in our example). The same issue with “knowing that we’re dealing with cached instances” mentioned above also applies.

Fortunately, latest EHCache versions provide a very usefull feature: copyOnRead.

With this flag turned on, EHCache will return you a deep copy of the object instance that is in the cache, not the instance itself. So mutability issue is solved.

Of course there is no free lunch, this convenient feature comes with its counterparts, the cost of serialization/deserialization because the default implementation is plain Java object serialization.

출처 - http://doanduyhai.wordpress.com/2012/07/01/cache-abstraction-in-spring-3/

@Caching With Multiple Keys

I have a service that takes in a DTO and returns some result: @Override public int foo(Bar bar) { .... } Bar is as follows (simplified): public class Bar { public int id; public String name; public String baz; @Override public int hashCode() { //this is already being defined for something else ... } @Override public boolean equals(Object o) { //this is already being defined for something else ... } } I want to use @Cacheable on the foo method; however, I want to hash on the id and name properties, but not baz. Is there a way to do this? java spring caching methods share|improve this question asked Nov 14 '12 at 15:24 Alex Beardsley 3,61572140

@Override
@Cacheable(key="#bar.name.concat('-').concat(#bar.id)")
public int foo(Bar bar) {
    ....
}

@Override
@Cacheable(key="#bar.hashCodeWithIdName")
public int foo(Bar bar) {
    ....
}

출처 - http://stackoverflow.com/questions/13381731/caching-with-multiple-keys

How should I implement request response with JMS?

The simplest solution is to use Camel as a Spring Remoting provider which allows you to hide all the JMS API from your business logic and letting Camel provide the request/response handling code for you.

However if you wish to write the JMS client code yourself, please read on how it works...

Using the JMS API to implement request-response

You might think at first that to implement request-response type operations in JMS that you should create a new consumer with a selector per request; or maybe create a new temporary queue per request.

Creating temporary destinations, consumers, producers and connections are all synchronous request-response operations with the broker and so should be avoided for processing each request as it results in lots of chat with the JMS broker.

The best way to implement request-response over JMS is to create a temporary queue and consumer per client on startup, set JMSReplyTo property on each message to the temporary queue and then use a correlationID on each message to correlate request messages to response messages. This avoids the overhead of creating and closing a consumer for each request (which is expensive). It also means you can share the same producer & consumer across many threads if you want (or pool them maybe).

The Lingo library is an implementation of Spring remoting using JMS. (Spring remoting is a kind of POJO based remoting where the remoting code is invisible to your business logic code).

It uses exactly this pattern; of using correlation IDs to correlate requests to responses. The server side just has to remember to put the inbound message's correlation ID on the response.

The actual class which does this is the MultiplexingRequestor . It may be just using Spring remoting with Lingo is the simplest way of implementing request response - or maybe you could just use Lingo's Requestor interface to keep the JMS semantics.

More details here

Client side

So the client side creates a consumer on a temporary queue as follows...

// client side
Destination tempDest = session.createTemporaryQueue();
MessageConsumer responseConsumer = session.createConsumer(tempDest);
...

// send a request..
message.setJMSReplyTo(tempDest)
message.setJMSCorrelationID(myCorrelationID);

producer.send(message);

Server side

public void onMessage(Message request) {

  Message response = session.createMessage();
  response.setJMSCorrelationID(request.getJMSCorrelationID())

  producer.send(request.getJMSReplyTo(), response)
}

Full Examples

Server Side

import org.apache.activemq.broker.BrokerService;
import org.apache.activemq.ActiveMQConnectionFactory;

import javax.jms.*;

public class Server implements MessageListener {
    private static int ackMode;
    private static String messageQueueName;
    private static String messageBrokerUrl;

    private Session session;
    private boolean transacted = false;
    private MessageProducer replyProducer;
    private MessageProtocol messageProtocol;

    static {
        messageBrokerUrl = "tcp://localhost:61616";
        messageQueueName = "client.messages";
        ackMode = Session.AUTO_ACKNOWLEDGE;
    }

    public Server() {
        try {
            //This message broker is embedded
            BrokerService broker = new BrokerService();
            broker.setPersistent(false);
            broker.setUseJmx(false);
            broker.addConnector(messageBrokerUrl);
            broker.start();
        } catch (Exception e) {
            //Handle the exception appropriately
        }

        //Delegating the handling of messages to another class, instantiate it before setting up JMS so it
        //is ready to handle messages
        this.messageProtocol = new MessageProtocol();
        this.setupMessageQueueConsumer();
    }

    private void setupMessageQueueConsumer() {
        ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(messageBrokerUrl);
        Connection connection;
        try {
            connection = connectionFactory.createConnection();
            connection.start();
            this.session = connection.createSession(this.transacted, ackMode);
            Destination adminQueue = this.session.createQueue(messageQueueName);

            //Setup a message producer to respond to messages from clients, we will get the destination
            //to send to from the JMSReplyTo header field from a Message
            this.replyProducer = this.session.createProducer(null);
            this.replyProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

            //Set up a consumer to consume messages off of the admin queue
            MessageConsumer consumer = this.session.createConsumer(adminQueue);
            consumer.setMessageListener(this);
        } catch (JMSException e) {
            //Handle the exception appropriately
        }
    }

    public void onMessage(Message message) {
        try {
            TextMessage response = this.session.createTextMessage();
            if (message instanceof TextMessage) {
                TextMessage txtMsg = (TextMessage) message;
                String messageText = txtMsg.getText();
                response.setText(this.messageProtocol.handleProtocolMessage(messageText));
            }

            //Set the correlation ID from the received message to be the correlation id of the response message
            //this lets the client identify which message this is a response to if it has more than
            //one outstanding message to the server
            response.setJMSCorrelationID(message.getJMSCorrelationID());

            //Send the response to the Destination specified by the JMSReplyTo field of the received message,
            //this is presumably a temporary queue created by the client
            this.replyProducer.send(message.getJMSReplyTo(), response);
        } catch (JMSException e) {
            //Handle the exception appropriately
        }
    }

    public static void main(String[] args) {
        new Server();
    }
}

Client Side

import org.apache.activemq.ActiveMQConnectionFactory;

import javax.jms.*;
import java.util.Random;

public class Client implements MessageListener {
    private static int ackMode;
    private static String clientQueueName;

    private boolean transacted = false;
    private MessageProducer producer;

    static {
        clientQueueName = "client.messages";
        ackMode = Session.AUTO_ACKNOWLEDGE;
    }

    public Client() {
        ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
        Connection connection;
        try {
            connection = connectionFactory.createConnection();
            connection.start();
            Session session = connection.createSession(transacted, ackMode);
            Destination adminQueue = session.createQueue(clientQueueName);

            //Setup a message producer to send message to the queue the server is consuming from
            this.producer = session.createProducer(adminQueue);
            this.producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

            //Create a temporary queue that this client will listen for responses on then create a consumer
            //that consumes message from this temporary queue...for a real application a client should reuse
            //the same temp queue for each message to the server...one temp queue per client
            Destination tempDest = session.createTemporaryQueue();
            MessageConsumer responseConsumer = session.createConsumer(tempDest);

            //This class will handle the messages to the temp queue as well
            responseConsumer.setMessageListener(this);

            //Now create the actual message you want to send
            TextMessage txtMessage = session.createTextMessage();
            txtMessage.setText("MyProtocolMessage");

            //Set the reply to field to the temp queue you created above, this is the queue the server
            //will respond to
            txtMessage.setJMSReplyTo(tempDest);

            //Set a correlation ID so when you get a response you know which sent message the response is for
            //If there is never more than one outstanding message to the server then the
            //same correlation ID can be used for all the messages...if there is more than one outstanding
            //message to the server you would presumably want to associate the correlation ID with this
            //message somehow...a Map works good
            String correlationId = this.createRandomString();
            txtMessage.setJMSCorrelationID(correlationId);
            this.producer.send(txtMessage);
        } catch (JMSException e) {
            //Handle the exception appropriately
        }
    }

    private String createRandomString() {
        Random random = new Random(System.currentTimeMillis());
        long randomLong = random.nextLong();
        return Long.toHexString(randomLong);
    }

    public void onMessage(Message message) {
        String messageText = null;
        try {
            if (message instanceof TextMessage) {
                TextMessage textMessage = (TextMessage) message;
                messageText = textMessage.getText();
                System.out.println("messageText = " + messageText);
            }
        } catch (JMSException e) {
            //Handle the exception appropriately
        }
    }

    public static void main(String[] args) {
        new Client();
    }
}

Protocol Class

This class is needed to run the client/server example above. Delegating the handling of messages to a seperate class is solely a personal preference.

public class MessageProtocol {
    public String handleProtocolMessage(String messageText) {
        String responseText;
        if ("MyProtocolMessage".equalsIgnoreCase(messageText)) {
            responseText = "I recognize your protocol message";
        } else {
            responseText = "Unknown protocol message: " + messageText;
        }
        
        return responseText;
    }
}

출처  - http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html