Caching in WCF

 

WCF 기반 서비스들이 공통으로 사용할 프레임워크를 만들면서, 오퍼레이션의 결과에 대한 캐싱 기능을 프레임워크 아키텍처에 포함 시키기로 했다.

 

서비스 오퍼레이션이 수행되기 전에 제어권을 받아 분기처리가 가능하도록 지원하는 IOperationInvoker 기반의 Caching Invoker를 제작하는데 캐시 API의 구현을 고민하게 되었다.

 

WCF에서도 ASP.NET의 Cache(System.Web.Caching.Cache)를 사용할 수 있지만, 이를 사용하기 위해서는 ASP.NET 호환성을 위해 서비스 클래스에 AspNetCompatibilityRequirements Attribute를 설정하고 Config 파일에 <serviceHostingEnvironment> 요소 aspNetCompatibilityEnabled 속성을 활성화 시켜 주어야 하는 등 프레임워크 연동에 제약을 가하게 되며, 더불어 이와같은 환경은 IIS 호스팅을 강제하기 때문에 셀프 호스팅 환경에서는 프레임워크의 캐싱 기능을 활용 할 수 없는, 즉 범용성의 저해가 발생해 버린다.

 

따라서 ASP.NET의 Cache는 적절치 못하다는 생각이다.

 

다른 방편으로, 전역 static 변수로 Dictionary 형태의 자료구조를 직접 관리할 수 있으나, 캐시 만료시간과 우선순위, Dependency 및 캐시 상태 변화에 따른 콜백 이벤트 등이 필요할 경우 이를 직접 구현해야 하니 역시 적절치 못하다 하겠다.

 

그러던 중, .NET 4.0에 추가된 MemoryCache라는 넘을 알게 되었다.

MSDN의 다음 한 구절이 나를 흥분(?)하게 만들었다.

ASP.NET Cache MemoryCache 클래스 사이의 주요 차이는 ASP.NET 응용 프로그램이 아닌 .NET Framework 응용 프로그램에서 사용할 수 있도록 MemoryCache 클래스가 변경되었다는 점입니다

 

왜 이걸 이제야 알게 되었단 말인가? 프레임워크 버전업에 따른 기본 API 학습을 게을리 한 탓이다. ㅡ,ㅡ;

MSDN을 찬찬히 훑어보니 딱! 원하던 그것이다.

 

WCF 서비스 기반에서 ASP.NET 호환성과 무관하게 캐싱 기능을 제공하기 위해 사용하기로 했다.

본격적인 적용 이전에 확인해야 할 사항은, 이 캐시가 ASP.NET 캐시처럼 응용 프로그램 도메인 내 전역 메모리를 사용하는가 하는 것이었다.

 

WCF 서비스가 매 호출마다 새로운 인스턴스를 만들거나 Caching Invoker가 매번 새롭게 생성된다면 MemoryCache를 인스턴스 범위를 넘어서도록 관리해야 한다.

 

간단히 테스트를 해보니 자연스럽게 응용 프로그램 도메인내에서 공유가 가능한 영역에서 캐시를 관리할 수 있다는 것을 확인하였다. 기본적인 활용 코드는 대략 다음과 같다.

 

ObjectCache cache = MemoryCache.Default;
CacheItemPolicy policy = new CacheItemPolicy();
policy.AbsoluteExpiration = aAbsoluteExpirationDateTime;
policy.SlidingExpiration = slidingExpirationTimeSpan;

                   

cache.Set(keyName, cacheValue, policy);

 

...

 

cache.Get(keyName);