SPRING
@Transactional 롤백이 안 되는 일을 실제로 겪다
같은 서비스 안에서 @Transactional 메서드를 자기 호출해 롤백이 안 되는 문제를 실제 운영 코드에서 겪고, 트랜잭션 이름을 직접 확인하며 별도 서비스로 분리해 해결한 과정을 기록합니다.
같은 서비스 안에서 @Transactional 메서드를 자기 호출해 롤백이 안 되는 문제를 실제 운영 코드에서 겪고, 트랜잭션 이름을 직접 확인하며 별도 서비스로 분리해 해결한 과정을 기록합니다.
같은 서비스 안에서 @Transactional 메서드를 자기 호출하면 프록시를 거치지 않아 REQUIRES_NEW가 적용되지 않고 일괄 롤백되는 원인과, 서비스 분리로 해결하는 방법을 흐름도와 함께 정리합니다.
JPA의 save와 saveAll을 각각 10,000건씩 테스트하여 실행 시간을 비교하고, saveAll이 더 빠른 이유를 프록시 기반 @Transactional 동작 원리로 설명합니다.
em.find()와 em.getReference()의 차이, 프록시 객체가 영속성 컨텍스트를 통해 초기화되는 과정, 프록시를 사용할 때 주의할 점과 확인 방법을 예제로 정리합니다.
FetchType.LAZY와 FetchType.EAGER로 연관된 Team을 조회하는 시점이 어떻게 달라지는지 프록시 관점에서 정리하고, 즉시 로딩이 일으키는 N+1 문제와 실무에서 지연 로딩을 쓰는 이유를 짚습니다.
같은 클래스 내부 호출에서 @Transactional이 적용되지 않는 self-invocation 문제의 원인과, REQUIRES_NEW 메서드를 하위 컴포넌트로 분리해 안전하게 쓰는 방법, 커넥션 점유 주의점을 정리합니다.