Proxy

Proxy 는 대리자 라는 뜻을 가지고 있다. 스프링부트의 구조를 간단히 정리해 보면, Controller -> Service -> Repository 및 Entity -> DB 로 요약할 수 있다. Controller 에서는 Service를 인젝션 받고, Service는 Repository를 인젝션 받는 형태이다. 이 중 Service 에서 비즈니스 로직과 DB의 Transaction을 활용하게 되는데, 이때 연관되는것이 Proxy 이다. 

 

Service의 메소드 중 @Transactional 어노테이션이 붙었을 경우, 스프링 컨테이너가 해당 Serivce를 바로 Controller에 인젝션 하지 않는다. 대신, 해당 Service와 동일한 Proxy 객체를 자동으로 동적으로 생성하여, 이를 Controller 에 인젝션을 해준다. 

Controller 입장에선 해당 Service와 동일하게 구성된 Proxy를 주입받았으므로, 그대로 메소드 호출을 통해 작업을 하면 된다. 

 

그러면 왜 Proxy를 쓰는가를 보면, 이는 AOP와 연관되어 있다. Transaction 수행 앞, 뒤로 특정 작업을 할 경우를 고려해서 이렇게 동작을 한다. (AOP 는 https://dean83.tistory.com/315 여기에 정리했다)

 

이를 통해 Transaction 수행 전, 후로 로깅을 하거나 공통 코드를 넣어 둘 수 있다. 

 

정리하자면, @Transactional 이 있는 Service의 경우

Controller -> Proxy -> Service -> Repository 및 Entity -> DB 라고 볼 수 있다. 

 

좀 더 구체적으로 살펴보면, 

Controller -> Proxy -> Transaction Intercepter -> Jpa Transaction Manager 가 트랜잭션 생성을 위해 Entity Manager 생성 -> Entity Manager 가 트랜잭션 시작 -> Service 메소드 호출 -> Entity Manager가 트랜잭션 종료 -> Entity Manager 도 종료됨.

• Transaction Intercepter 는 Jpa Transaction Manager 를 주입받아, 트랜잭션 작업을 이쪽으로 위임 한다.
• Jpa Transaction Manager 는 PlatformTransactionManager 인터페이스를 구현한 구현체로, 트랜잭션 단위별로 Entity Manager 를 생성 하여 작업한다.