여러 저장소가 하나의 트랜잭션을 공유해야 하는 요구 때문에 서비스가 JDBC Connection을 직접 만들어 인자로 넘기면서 저장소 인터페이스의 캡슐화가 깨진 구현을, 코드 리뷰를 계기로 단계적으로 개선하는 과정을 다룬다. 마지막엔 그 결과가 Spring의 트랜잭션 동기화와 맞닿아 있음을 코드로 확인한다.
핵심 포인트- 서비스가 Connection을 생성·전달하는 첫 구현은 동작하지만 비즈니스 계층이 JDBC 생명주기를 알고 저장소 인터페이스가 인프라 타입을 노출 — 리뷰에서 캡슐화 문제로 지적
- 트랜잭션 매니저가 Connection 생성·비즈니스 로직 실행·commit·rollback을 감싸 서비스는 실행할 로직만 전달, JDBC 세부에서 분리
- 여러 요청 스레드의 Connection이 섞이지 않도록 ThreadLocal에 스레드별 Connection을 보관해, 매니저가 넣고 저장소 구현체가 꺼내 쓰면 인터페이스에 인프라 타입을 노출하지 않고도 같은 트랜잭션 공유
- 직접 만든 트랜잭션 매니저 + ThreadLocal 구조가 Spring @Transactional의 TransactionSynchronizationManager와 유사함을 코드로 확인 — Spring도 스레드에 자원을 묶어 저장소가 Connection을 명시적으로 받지 않게 함
왜 읽나@Transactional을 블랙박스로 쓰던 개발자에게 트랜잭션 매니저와 ThreadLocal을 직접 구현해보며 Spring 내부 동작을 캡슐화 관점에서 이해하게 해주는 10분 톡.