Loading...
Spring Framework Reference Documentation 7.0.2의 JCache (JSR-107) Annotations의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
version 4.1부터 Spring의 caching 추상화는 JCache 표준
(JSR-107) 어노테이션인 @CacheResult, @CachePut, @CacheRemove, 그리고 @CacheRemoveAll과
@CacheDefaults, @CacheKey, @CacheValue companion들을 완전히 지원합니다.
이러한 어노테이션은 캐시 저장소를 JSR-107로 마이그레이션하지 않고도 사용할 수 있습니다.
내부 구현은 Spring의 caching 추상화를 사용하며 명세를 준수하는 기본
CacheResolver와 KeyGenerator 구현을 제공합니다. 다시 말해, 이미 Spring의 caching 추상화를
사용하고 있다면, 캐시 저장소를 변경하지 않고(또는 설정을 변경하지 않고)
이러한 표준 어노테이션으로 전환할 수 있습니다.
Spring의 caching 어노테이션에 익숙한 사람들을 위해, 다음 표는 Spring 어노테이션과 그에 상응하는 JSR-107 어노테이션들 간의 주요 차이점을 설명합니다:
| Spring | JSR-107 | Remark |
|---|---|---|
@Cacheable | @CacheResult | 상당히 유사합니다. @CacheResult는 특정 예외를 캐시할 수 있으며<br>캐시의 내용과 상관없이 메서드의 실행을 강제할 수 있습니다. |
@CachePut | @CachePut | Spring은 메서드 호출의 결과로 캐시를 업데이트하는 반면, JCache는<br>@CacheValue로 어노테이션된 인수로 결과가 전달되기를 요구합니다.<br>이러한 차이로 인해 JCache는 실제 메서드 호출 이전 또는 이후에<br>캐시를 업데이트할 수 있습니다. |
@CacheEvict | @CacheRemove | 상당히 유사합니다. @CacheRemove는 메서드 호출이 예외를<br>발생시켰을 때 조건부 제거를 지원합니다. |
@CacheEvict(allEntries=true) | @CacheRemoveAll | @CacheRemove를 참조하십시오. |
@CacheConfig | @CacheDefaults | 동일한 개념을 유사한 방식으로 구성할 수 있게 해줍니다. |
Table 1. Spring vs. JSR-107 caching 어노테이션
JCache에는 javax.cache.annotation.CacheResolver 개념이 있으며,
이는 JCache가 단일 캐시만 지원한다는 점을 제외하면 Spring의 CacheResolver 인터페이스와
동일합니다. 기본적으로, 간단한 구현은 어노테이션에 선언된 이름을 기반으로 사용할
캐시를 조회합니다. 어노테이션에 캐시 이름이 지정되지 않은 경우 기본값이
자동으로 생성된다는 점에 유의해야 합니다.
더 자세한 내용은
@CacheResult#cacheName()의 javadoc을 참조하십시오.
CacheResolver 인스턴스는 CacheResolverFactory에 의해 조회됩니다.
다음 예제에서 볼 수 있듯이 각 캐시 작업마다 팩토리를
커스터마이즈하는 것이 가능합니다:
1@CacheResult(cacheNames="books", cacheResolverFactory=MyCacheResolverFactory.class) (1) 2public Book findBook(ISBN isbn)
| 1 | 이 작업에 대한 팩토리를 커스터마이징합니다. |
참조된 모든 클래스에 대해 Spring은 주어진 타입의 빈을 찾으려고 시도합니다.<br>둘 이상의 일치 항목이 존재하면 새 인스턴스가 생성되며, 의존성 주입과 같은<br>일반적인 빈 라이프사이클 콜백을 사용할 수 있습니다.
Key는 Spring의 KeyGenerator와 동일한 목적을 수행하는
javax.cache.annotation.CacheKeyGenerator에 의해 생성됩니다. 기본적으로 하나 이상의
파라미터가 @CacheKey로 어노테이션되지 않는 한 모든 메서드 인수가 고려됩니다.
이는 Spring의 사용자 정의 키 생성 선언
과 유사합니다.
예를 들어, 다음은 동일한 작업으로, 하나는 Spring의 추상화를 사용하고 다른 하나는 JCache를 사용합니다:
1@Cacheable(cacheNames="books", key="#isbn") 2public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed) 3 4@CacheResult(cacheName="books") 5public Book findBook(@CacheKey ISBN isbn, boolean checkWarehouse, boolean includeUsed)
CacheResolverFactory를 지정하는 것과 유사하게 작업에서 CacheKeyResolver를
지정할 수도 있습니다.
JCache는 어노테이션된 메서드에서 발생한 예외를 관리할 수 있습니다. 이는 캐시의 업데이트를 방지할 수 있지만, 메서드를 다시 호출하는 대신 실패의 지표로 예외를 캐시할 수도 있습니다.
ISBN의 구조가 잘못된 경우
InvalidIsbnNotFoundException이 발생한다고 가정해 봅시다. 이는 영구적인 실패입니다
(이러한 파라미터로는 어떤 책도 검색될 수 없음). 다음 예제는 예외를 캐시하여
동일한 잘못된 ISBN으로 이후 호출 시 메서드를 다시 호출하는 대신
캐시된 예외를 직접 발생시키도록 합니다:
1@CacheResult(cacheName="books", exceptionCacheName="failures" 2 cachedExceptions = InvalidIsbnNotFoundException.class) 3public Book findBook(ISBN isbn)
Spring의 선언적 어노테이션 지원과 함께 JSR-107 지원을 활성화하기 위해
특별히 해야 할 일은 없습니다. @EnableCaching과 cache:annotation-driven
XML 요소는 JSR-107 API와 spring-context-support 모듈이 클래스패스에 존재하는 경우
자동으로 JCache 지원을 활성화합니다.
사용 사례에 따라 선택은 기본적으로 여러분에게 달려 있습니다. 일부 서비스에는 JSR-107 API를<br>사용하고 다른 서비스에는 Spring의 자체 어노테이션을 사용하는 방식으로 혼합해서 사용할 수도<br>있습니다. 그러나 이러한 서비스가 동일한 캐시에 영향을 미치는 경우, 일관되고 동일한 키<br>생성 구현을 사용해야 합니다.
Declarative Annotation-based Caching
Declarative XML-based Caching