2016-08-19 6 views
0

그래서,주석을 통해 개체 형식에서 캐시를 만들기

내가 캐시를 점화하는 기존의 캐싱 (으로 Ehcache를) 변환을 시도하고, 주석을 봄으로 마이그레이션하고있다. 어노테이션을 기존의 캐시와 동일하게 작동시키는 데 어려움이 있습니다. 기존 캐시는 새로운 클래스를 캐시 할 때마다 자동으로 생성되며 새 캐시는 객체 클래스와 동일한 이름을 갖습니다.

모든 현재 캐시 로직 (대부분의 일반 CRUD 연산 로직과 함께)은 모든 영구 객체에 대해 확장 된 추상 클래스에 있습니다. Spring 애노테이션을 연구 할 때 메소드에 캐시 이름을 정의 할 필요가있는 것처럼 보입니다 - 모든 객체를 동일한 캐시에 넣기를 원하지 않는 한 명백히 추상 클래스에서는 작동하지 않습니다 (가능하지만 확실히 이상). 이상적으로 캐시 이름을 "# this.class.toString"으로 지정 하겠지만 캐시 이름에 SPEL이 허용되지 않습니다 (키에 있음).

캐시를 동적으로 해결하는 유일한 방법은 자신의 캐시 해결 프로그램을 만드는 것입니다.하지만 어떤 이유로 IgniteCache가 springframework Cache를 확장하지는 않지만 javax Cache와 캐시 해결자가 이전을 반환해야합니다. 그래서 스프링 애노테이션으로 Ignite 캐시가 어떻게 작동하는지 명확하지 않습니다.

이것은 꽤 간단한 사용 사례처럼 보입니다. 따라서 스프링 주석은 메소드에 명시적인 이름을 제공해야합니다. 중요한 크기의 대부분의 어플리케이션이 퍼시스턴스 메소드를 추상화한다고 가정 할 때, 몇 가지 중요한 문서를 놓쳐 버린 것 같았지만 확실히 찾을 수 없었습니다. 구체적인 구현에서 캐시의 이름을 지정하는 방법이 있습니까?하지만 캐싱 주석을 추상 메소드에 보관 하시겠습니까?

감사합니다.

+0

EhCache에서 Spring 어노테이션을 사용 했습니까? 그렇다면 어떻게 작동 했습니까? 그렇지 않다면 처음부터 사용하는 이유는 무엇입니까? Ignite API를 직접 사용하지 않는 이유는 무엇입니까? –

답변

1

귀하의 질문은 상당히 밀집되어 있으며 귀하가하려는 일이 명확하지 않습니다. "기존 캐시"란 무엇입니까? 내가 추측하는 것을 실제로 캐싱하는 장소를 표시하는 방법이 필요합니다. 캐시 주석을 거기에 넣어야한다고 이미 알고 있다고 가정합니다.

자동으로 캐시를 생성하는 경우, 다른 캐싱 시스템 을 구현하려고 시도하지 않습니다. 기존 캐시 인프라로 캐시 주석으로 마이그레이션 한 다음 ignite로 마이그레이션하십시오.

둘 다 수행하는 것처럼 보자. 당신은 맞습니다 CacheResolver가는 방법이며 일반 org.springframework.cache.Cache 또는 javax.cache.Cache 중 하나에 적응할 수 있습니다. 당신의 CacheResolver 구현에

  • 을 주입 메서드 호출을 기반으로
  • 구성되어있는 캐시 관리자를 사용하는 캐시의 이름을 알아 내기 : 당신이 작동하는 설정이 있으면, 나는 다음을 수행 할 것 (메서드의 반환 유형을 가져오고 FQN 추출)
  • 캐시 관리자에 이러한 캐시가 있는지 확인하십시오. 그렇지 않으면 반환하십시오. 이 새로운 캐시를 생성하고 추가 한 다음 JCacheCacheManager를 사용하는 경우

, 새 캐시를 만들 addCache를 호출 할 수 있음을 반환하고 JCacheCache에 결과를 포장하지 않는 경우 서명을 준수합니다 CacheResolver입니다.

마지막주의 사항 : 자동으로 FQN을 기반으로 캐시를 만드는 것은 나에게 취약합니다. 특히 하위 클래스가있는 경우 더욱 그렇습니다.당신이 만드는 캐시와 당신이 그들에게 적용하는 세팅 (만료, 크기 등)에 대한 약간의 통제가 필요하다.