어노테이션 사용법 암기 수준인지, 프록시·매니저·동기화 매니저의 *역할 분리* 모델까지 들고 와서 자기 호출·전파·롤백 규칙 같은 문제를 같은 모델 위에서 설명할 수 있는지를 가른다.
선언적 트랜잭션에서는 @Transactional이 붙은 빈이 AOP 프록시로 감싸진다. 외부에서 그 메서드가 호출되면 프록시가 먼저 PlatformTransactionManager를 통해 트랜잭션을 시작하고, 필요한 커넥션을 받아 트랜잭션 동기화 매니저에 ThreadLocal로 바인딩한다. 그 뒤 실제 비즈니스 로직이 같은 스레드 문맥에서 동기화된 자원을 공유하며 실행되고, 정상 종료 시 커밋, 롤백 규칙에 걸리는 예외 시 롤백한 뒤 자원을 정리한다. PlatformTransactionManager 추상화 덕분에 JDBC·JPA·JTA 구현체가 바뀌어도 애플리케이션 코드는 그대로 둘 수 있고, 대신 "프록시를 거치지 않으면 이 흐름이 통째로 작동하지 않는다"는 프록시 기반의 한계가 같이 따라온다.
롤백이 안 도는 버그를 추적하면서 자기 호출·체크 예외·`rollbackFor`까지 원인 후보를 좁혀본 경험이 있다면, 그 디버깅 과정을 답변의 "프록시 한계" 설명으로 가져올 수 있다
전파 옵션(`REQUIRES_NEW`, `NESTED` 등)을 조정해 부분 실패·정합성 문제를 해결한 경험이 있다면, 동기화 매니저와 커넥션 공유 이야기를 본인 사례로 풀 수 있다
커넥션 누수·풀 고갈을 의심하며 트랜잭션 보유 시간을 줄여본 경험이 있다면, "트랜잭션 경계와 커넥션 점유" 관점을 자연스럽게 엮을 수 있다
JDBC→JPA 전환에서 트랜잭션 매니저 구현체를 바꾼 경험이 있다면 `PlatformTransactionManager` 추상화 이점을 본인 경험으로 말할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.