Configuring the Cache Storage

cache abstraction은 여러 storage integration option을 제공합니다. 이를 사용하려면, 적절한 CacheManager(Cache 인스턴스를 제어하고 관리하며 storage를 위해 이를 검색하는 데 사용할 수 있는 엔티티)를 선언해야 합니다.

JDK ConcurrentMap-based Cache

JDK 기반 Cache 구현은 org.springframework.cache.concurrent 패키지 아래에 위치합니다. 이는 ConcurrentHashMap을 백엔드 Cache 저장소로 사용할 수 있게 해줍니다. 다음 예제는 두 개의 cache를 구성하는 방법을 보여줍니다:

1@Bean
2ConcurrentMapCacheFactoryBean defaultCache() {
3	ConcurrentMapCacheFactoryBean cache = new ConcurrentMapCacheFactoryBean();
4	cache.setName("default");
5	return cache;
6}
7
8@Bean
9ConcurrentMapCacheFactoryBean booksCache() {
10	ConcurrentMapCacheFactoryBean cache = new ConcurrentMapCacheFactoryBean();
11	cache.setName("books");
12	return cache;
13}
14
15@Bean
16CacheManager cacheManager(ConcurrentMapCache defaultCache, ConcurrentMapCache booksCache) {
17
18	SimpleCacheManager cacheManager = new SimpleCacheManager();
19	cacheManager.setCaches(Set.of(defaultCache, booksCache));
20	return cacheManager;
21}

1@Bean
2fun defaultCache(): ConcurrentMapCacheFactoryBean {
3	return ConcurrentMapCacheFactoryBean().apply {
4		setName("default")
5	}
6}
7
8@Bean
9fun booksCache(): ConcurrentMapCacheFactoryBean {
10	return ConcurrentMapCacheFactoryBean().apply {
11		setName("books")
12	}
13}
14
15@Bean
16fun cacheManager(defaultCache: ConcurrentMapCache, booksCache: ConcurrentMapCache): CacheManager {
17	return SimpleCacheManager().apply {
18		setCaches(setOf(defaultCache, booksCache))
19	}
20}

1<!-- simple cache manager -->
2<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
3	<property name="caches">
4		<set>
5			<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" name="default"/>
6			<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" name="books"/>
7		</set>
8	</property>
9</bean>

앞의 snippet은 SimpleCacheManager를 사용하여 default와 books라는 이름의 두 개의 nested ConcurrentMapCache 인스턴스에 대한 CacheManager를 생성합니다.

이름은 각 cache에 대해 직접 구성된다는 점에 유의하십시오.

cache는 애플리케이션에 의해 생성되므로, 애플리케이션의 라이프사이클에 바인딩되어 기본적인 use case, test 또는 simple 애플리케이션에 적합합니다. cache는 확장성이 좋고 매우 빠르지만, 어떠한 management, persistence capability 또는 eviction contract도 제공하지 않습니다.

Ehcache-based Cache

Ehcache 3.x는 완전히 JSR-107을 준수하며, 이를 위해 별도의 지원이 필요하지 않습니다. 자세한 내용은 JSR-107 Cache를 참조하십시오.

Caffeine Cache

Caffeine은 Guava의 cache를 Java 8로 다시 작성한 것이며, 그 구현은 org.springframework.cache.caffeine 패키지에 위치하며 Caffeine의 여러 feature에 대한 access를 제공합니다.

다음 예제는 cache를 on demand로 생성하는 CacheManager를 구성합니다:

1@Bean
2CacheManager cacheManager() {
3	return new CaffeineCacheManager();
4}

1@Bean
2fun cacheManager(): CacheManager {
3	return CaffeineCacheManager()
4}

1<bean id="cacheManager" class="org.springframework.cache.caffeine.CaffeineCacheManager"/>

또한 사용할 cache를 명시적으로 제공할 수도 있습니다. 이 경우, manager는 그것들만 사용 가능하게 만듭니다. 다음 예제는 그 방법을 보여줍니다:

1@Bean
2CacheManager cacheManager() {
3	CaffeineCacheManager cacheManager = new CaffeineCacheManager();
4	cacheManager.setCacheNames(List.of("default", "books"));
5	return cacheManager;
6}

1@Bean
2fun cacheManager(): CacheManager {
3	return CaffeineCacheManager("default", "books")
4}

1<bean id="cacheManager" class="org.springframework.cache.caffeine.CaffeineCacheManager">
2	<property name="cacheNames">
3		<set>
4			<value>default</value>
5			<value>books</value>
6		</set>
7	</property>
8</bean>

Caffeine CacheManager는 custom Caffeine 및 CacheLoader도 지원합니다. 이에 대한 자세한 내용은 Caffeine documentation을 참조하십시오.

GemFire-based Cache

GemFire는 memory-oriented, disk-backed, elastically scalable, continuously available, active(내장된 pattern-based subscription notification 포함), globally replicated database이며, 완전한 기능의 edge caching을 제공합니다. CacheManager로서 (및 그 이상으로) GemFire를 사용하는 방법에 대한 자세한 내용은 Spring Data GemFire reference documentation을 참조하십시오.

JSR-107 Cache

Spring의 caching abstraction은 JSR-107을 준수하는 cache도 사용할 수 있습니다. JCache 구현은 org.springframework.cache.jcache 패키지에 위치합니다.

마찬가지로, 이를 사용하려면 적절한 CacheManager를 선언해야 합니다. 다음 예제는 그 방법을 보여줍니다:

1@Bean
2javax.cache.CacheManager jCacheManager() {
3	CachingProvider cachingProvider = Caching.getCachingProvider();
4	return cachingProvider.getCacheManager();
5}
6
7@Bean
8org.springframework.cache.CacheManager cacheManager(javax.cache.CacheManager jCacheManager) {
9	return new JCacheCacheManager(jCacheManager);
10}

1@Bean
2fun jCacheManager(): javax.cache.CacheManager {
3	val cachingProvider = Caching.getCachingProvider()
4	return cachingProvider.getCacheManager()
5}
6
7@Bean
8fun cacheManager(jCacheManager: javax.cache.CacheManager): org.springframework.cache.CacheManager {
9	return JCacheCacheManager(jCacheManager)
10}

1<bean id="cacheManager"
2	  class="org.springframework.cache.jcache.JCacheCacheManager"
3	  p:cache-manager-ref="jCacheManager"/>
4
5<!-- JSR-107 cache manager setup  -->
6<bean id="jCacheManager" .../>

Dealing with Caches without a Backing Store

때때로 environment를 전환하거나 testing을 할 때, 실제 backing cache가 구성되지 않은 상태에서 cache declaration이 존재할 수 있습니다. 이는 잘못된 configuration이므로, caching infrastructure가 적절한 store를 찾을 수 없기 때문에 runtime 시에 exception이 발생합니다.

이러한 상황에서, cache declaration을 제거하는 대신(이는 귀찮을 수 있습니다), caching을 수행하지 않는 simple dummy cache를 wiring하여 사용할 수 있습니다. 즉, cache된 method가 매번 호출되도록 강제합니다. 다음 예제는 그 방법을 보여줍니다:

1@Bean
2CacheManager cacheManager(CacheManager jdkCache, CacheManager gemfireCache) {
3	CompositeCacheManager cacheManager = new CompositeCacheManager();
4	cacheManager.setCacheManagers(List.of(jdkCache, gemfireCache));
5	cacheManager.setFallbackToNoOpCache(true);
6	return cacheManager;
7}

1@Bean
2fun cacheManager(jdkCache: CacheManager, gemfireCache: CacheManager): CacheManager {
3	return CompositeCacheManager().apply {
4		setCacheManagers(listOf(jdkCache, gemfireCache))
5		setFallbackToNoOpCache(true)
6	}
7}

1<bean id="cacheManager" class="org.springframework.cache.support.CompositeCacheManager">
2	<property name="cacheManagers">
3		<list>
4			<ref bean="jdkCache"/>
5			<ref bean="gemfireCache"/>
6		</list>
7	</property>
8	<property name="fallbackToNoOpCache" value="true"/>
9</bean>

앞의 CompositeCacheManager는 여러 CacheManager 인스턴스를 체인하고, fallbackToNoOpCache flag를 통해, 구성된 cache manager에서 처리하지 않는 모든 definition에 대해 no-op cache를 추가합니다. 즉, 예제에서 앞서 구성한 jdkCache 또는 gemfireCache에서 찾을 수 없는 모든 cache definition은 정보를 저장하지 않는 no-op cache에 의해 처리되며, 그 결과 target method가 매번 호출됩니다.