@Transactional을 "붙이면 동작한다"로 알고 있는지, 아니면 프록시 기반 AOP의 한계와 self-invocation까지 이해하고 우회 패턴을 제시할 수 있는지를 가른다.
스프링 기본의 @Transactional은 빈(Bean)을 감싼 프록시가 메서드 호출을 가로챌 때 트랜잭션 어드바이스를 적용한다. private 메서드는 프록시가 오버라이드할 수 없어 어드바이스가 걸리지 않고, 같은 클래스 내부에서 this.method()로 부르는 self-invocation도 프록시를 거치지 않기 때문에 트랜잭션이 시작되지 않는다. 그래서 트랜잭션 경계가 필요한 메서드는 public으로 두고, 분리가 필요하면 메서드를 다른 빈으로 빼서 외부 호출로 만들어야 한다. AspectJ 위빙을 쓰면 프록시 한계를 우회할 수 있지만 그건 별도 설정이 필요한 예외 경로다.
트랜잭션이 "안 도는" 사고를 디버깅하다 self-invocation을 발견한 경험이 있다면 "호출 경로가 곧 어드바이스 적용 여부다"로 일반화할 수 있다
내부 호출을 외부 빈으로 분리해 트랜잭션 경계를 정상화한 경험이 있다면 우회 패턴의 실제 사례로 보여 줄 수 있다
AspectJ 위빙이나 TransactionTemplate을 도입해 본 경험이 있다면 프록시 한계의 대안 이야기로 이어갈 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.