[Spring] self-invocation 의 문제와 사용법

저번에 eh-cache관련되서, self invocation의 문제에 대해서 잠깐 언급했다.

위와 같이, cacheable로 메소드를 감싸면, 해당 메소드에서 생성한 Post객체는 주소가 달라지지않고, 캐싱하게된다.

해당 eh캐시는, 자바 기반이고 스프링프레임워크와 생명주기를 함께한다.

하여

이런식으로 같은 주소를 가지게 된다.

 

그런데 여기서 문제가 있다.

self invocation을 강제로 발생시켜서 확인해보자.

기존의 cacheTest의 메소드를, 호출하는 것이 아니라, 컨트롤러에서 해당 foo()를 호출하고, foo에서 cacheTest를 호출하게 한다.

이렇게 되는 경우에는,당연히 cacheTest를 호출하는거고, 캐시를 타는거니까 캐싱이 타게될 것같지만

다른 주소를 호출하게 된다. 즉 캐싱이 먹지않는다.

이유가 무엇일까?

 

 

 

만약에 서비스가 business서비스라고 생각해보자

프록시는, 특정 메소드의 앞뒤에서 처리하는 개념이다. 즉 aop도 이와 같다.

프록시 -> 서비스 -> 프록시 이런 과정으로 처리를 하는데 서비스에서 자신의 서비스의 다른 메소드를 호출하면, 프록시의 객체를 거치지 않게된다.

 

쉽게 정리를 하면 이와 같다. ehcache는 메모리 위에 올려놓고 사용하기 위해 존재한다.

 

이때, 캐시는 프록시 기반으로 동작하는데, 클래스의 모든 요청, 응답의 인터셉터에 의해 생성되기 때문에

같은 클래스 내 선언, 즉 self invocation의 경우에는 프록시를 타지 않게 되어, 캐싱에서의 문제가 존재하게 된다.

 

해당관련 클래스에서는 해결 방법이 이렇게존재한다.

 

1.AopContext를 사용한다.

AopContext는 현재 Aop호출에 대한 정보를 얻기 위한 추상 클래스이다.

해당 AopContext를 활용해서, 프록시 객체에서의 메소드를 실행할수있다.

 

해당 방법을 사용하면,되고 해당 방법을 사용하기 위해서는 spring boot에서는 자동 지원되기때문에 어노테이션만 붙여주면된다.

추후에, 프록시와 메소드의 동작 과정에 대해서 심화과정을 포스팅해야겠다.

왜냐면 프록시와 메소드의 관계 프록시 별 메소드관계에 대해서 정확하고 깊게 이해하고싶어서이다.

 

2. IOC컨테이너 Bean 활용

 

두번째 방법은 Ioc 컨테이너에 등록된 자기 자신의 빈을 사용하는 방법이다.

 

this가 아닌, 자기 자신을 self로, bean을 선언, 및 주입하여 메소드를 호출하는 것이다.

bean을 통해 호출하기 때문에, 프록시를 타고 호출하게 되는 효과가 있다.

 

3. Spring Aop의 weaving 방식을 AspectJ의 weaving 방식으로 변환

AspectJ는 바이트 코드를 조작하는 방식이라, self Invocation을 방지한다고 한다.

이건 추후 포스팅에서 자세히 다뤄보자

 

 

이번 포스팅을 통해 공부가 필요하여, 추가 포스팅할 목록

1. AspectJ 와 Spring Aop의 차이 및, AspectJ 공부

2. weaving 방식이라는 용어의 뜻의 이해 

3. Ioc 컨테이너의 빈관리 및, 빈과 프록시의 동작과정

4. 프록시 독자적 동작 방식 세분화 공부