조용한 개발 노트

15편에서는 Spring Transaction을“commit/rollback 기능”이 아니라 “실행 흐름을 묶는 경계(boundary)”로 이해해야 한다는 점을 정리했습니다.이번 글에서는 이 관점을 한 단계 더 현실로 끌어내려,실제 코드에서 트랜잭션을 어떻게 설계하고 어디서 나눠야 하는지를 Spring 공식 문서 기준으로 정리해보겠습니다.즉,“그래서 내 서비스 메서드에서는 어떻게 판단해야 할까?”에 대한 답입니다.1. Spring Transaction 설계의 출발점Spring 공식 문서에서 트랜잭션 설계의 출발점은 언제나 동일합니다.하나의 트랜잭션은 하나의 유스케이스를 표현해야 한다그래서 트랜잭션을 설계할 때 가장 먼저 던져야 할 질문은 옵션이 아니라 이것입니다.이 메서드는 하나의 유스케이스인가?이 질문..

1편부터 14편까지, 이 시리즈에서는 Spring Transaction 공식 문서를 기준으로트랜잭션이 왜 ThreadLocal로 관리되는지@Transactional이 어떻게 동작하는지전파, 롤백, 격리, 비동기, 이벤트가 왜 필요한지를 하나의 흐름으로 정리해왔습니다.이번 글에서는 개별 옵션 설명을 멈추고,Spring Transaction을 어떤 관점으로 이해해야 하는지를 한 문장으로 정리해보겠습니다.1. 우리가 흔히 하는 착각트랜잭션을 처음 배울 때, 대부분 이렇게 이해합니다.“트랜잭션은 commit/rollback을 자동으로 해주는 기능”그래서:@Transactional을 어디에 붙일지 고민하고옵션을 조합해서 동작을 맞추려 합니다하지만 이 접근은 항상 같은 문제로 이어집니다.왜 여기서는 안 걸리지?왜 ..

13편에서는 트랜잭션과 비동기가“같은 실행 흐름을 공유할 수 없는 이유”를 ThreadLocal 기반 구조로 설명했습니다.그 논의의 끝에는 항상 다음 질문이 남습니다.“그럼 트랜잭션이 끝난 뒤에 무언가를 안전하게 실행하려면 어떻게 해야 할까?”이 질문에 대한 Spring의 공식적인 답이 바로트랜잭션 이벤트(Transaction Event)입니다.1. 트랜잭션 이벤트는 무엇을 해결하려고 등장했을까다음과 같은 요구는 실무에서 매우 흔합니다.주문이 성공적으로 저장된 뒤 알림 발송결제가 확정된 뒤 통계 집계회원 가입이 완료된 뒤 환영 메일 발송이 작업들의 공통점은:“트랜잭션이 성공했을 때만 실행돼야 한다”는 점입니다.하지만 단순히 메서드 끝에서 실행하면,아직 커밋되지 않았거나곧 롤백될 수도 있는 상태에서 외부 ..

12편에서는 @Transactional(readOnly = true)가“쓰기 방지 규칙이 아니라 의도를 표현하는 힌트”라는 점을 살펴봤습니다.이제 트랜잭션 시리즈에서 가장 많은 실무 사고를 만드는 조합,트랜잭션 + 비동기로 넘어가겠습니다.많은 개발자가 다음과 같은 코드를 자연스럽게 작성합니다.@Transactionalpublic void process() { saveOrder(); asyncService.sendMessage(); // @Async}그리고 이렇게 기대합니다.“비동기 작업도 같은 트랜잭션 안에서 실행되겠지?”하지만 이 기대는거의 항상 틀립니다.1. 충돌의 출발점: ThreadLocal1편에서 다뤘듯이, Spring Transaction은ThreadLocal을 기반으로 동작합니다...

11편에서는 Isolation을 조정해야 하는 순간이“매우 제한적이며, 대부분은 다른 방법이 우선”이라는 점을 실무 시나리오로 정리했습니다.이번 글에서는 @Transactional 옵션 중 가장 많이 오해되는 값,readOnly를 다뤄보겠습니다.readOnly를 보면 많은 개발자가 이렇게 생각합니다.“readOnly = true면 DB에 쓰기가 절대 안 나가겠지?”하지만 Spring 공식 문서 관점에서 이 이해는정확하지 않습니다.1. readOnly는 무엇을 보장하는가결론부터 말하면,readOnly는 “금지”가 아니라 “힌트”입니다.즉,readOnly = true라고 해서쓰기 SQL이 물리적으로 차단되는 것은 아닙니다Spring 공식 문서가 말하는 readOnly의 의미는 다음에 가깝습니다.“이 트랜잭션..

10편에서는 Spring Transaction에서“왜 대부분의 경우 Isolation은 DEFAULT로 두는가”를 현실적인 이유로 살펴봤습니다.요약하면,Isolation은 DB의 영역이고, 애플리케이션은 함부로 개입하지 않는 것이 기본이었습니다.하지만 실무에서는 다음과 같은 질문을 피할 수 없습니다.“그래도 이건 DEFAULT로는 안 되는데?”이번 글에서는정말로 Isolation을 고려해야 하는 순간을 실제 시나리오로 정리해보겠습니다.1. Isolation을 건드리기 전에 반드시 해야 할 것Isolation을 올리는 것은마지막 수단입니다.그래서 공식 문서와 실무에서는 다음 순서를 강하게 권장합니다.비즈니스 제약으로 해결 (UNIQUE, 상태 전이)애플리케이션 레벨 제어그래도 안 되면 Isolation 고..

9편에서는 rollbackFor / noRollbackFor를 통해“어떤 실패를 트랜잭션 실패로 볼 것인가”를 예외 설계 관점에서 정리했습니다.이제 트랜잭션 옵션 중 마지막으로 남은 축,격리 수준(Isolation)으로 넘어가 보겠습니다.많은 개발자가 Isolation을 보면 이렇게 반응합니다.“이거 중요해 보이는데…근데 실무에서는 거의 안 만지지 않나?”이 인식은거의 맞습니다.이번 글에서는 왜 Spring 공식 문서와 실무 모두에서“Isolation은 대부분 기본값으로 둔다”고 말하는지를 현실적인 이유로 설명해보겠습니다.1. Isolation은 무엇을 제어하는 옵션일까Isolation은“동시에 실행되는 트랜잭션들이 서로의 변경을 어디까지 볼 수 있는가”를 정의하는 옵션입니다.대표적인 격리 수준은 다음 ..

8편에서는 Spring Transaction의 기본 롤백 규칙,“왜 RuntimeException만 롤백되는가”를 설계 철학 관점에서 살펴봤습니다.그 이해를 바탕으로 이제 다음 질문으로 넘어가야 합니다.그럼 rollbackFor는 언제 써야 할까?그리고 왜 이 옵션은 기본이 아닐까?이 질문에 답하지 못하면,rollbackFor를 남용하거나아예 쓰지 않다가 사고를 내거나예외 설계와 트랜잭션이 뒤엉킵니다1. rollbackFor는 무엇을 바꾸는 옵션일까rollbackFor는 Spring의 기본 롤백 규칙을“명시적으로 덮어쓰는 선언”입니다.기본 규칙은:RuntimeException → 롤백Checked Exception → 커밋rollbackFor는 이 중Checked Exception을 롤백 대상으로 승격시..

7편에서는 NESTED 전파 옵션이“이론적으로는 가능하지만, 실무에서는 거의 선택되지 않는 이유”를 살펴봤습니다.이제 Spring Transaction에서 가장 많이 오해되고, 가장 많은 장애를 만드는 질문으로 넘어가야 합니다.왜 RuntimeException만 롤백되고, Checked Exception은 기본 커밋될까?이 질문에 답하지 못하면,“분명 예외가 났는데 왜 커밋됐지?”“rollbackFor를 왜 써야 하지?”“예외 설계는 트랜잭션과 무슨 관계지?”같은 혼란을 끝없이 반복하게 됩니다.1. 먼저 사실부터 정리하자Spring의 기본 롤백 규칙은 아주 명확합니다.RuntimeException과 Error → 롤백Checked Exception → 커밋이 규칙은 버그도 아니고,JPA의 제약도 아닙니다..

6편에서는 REQUIRES_NEW가“기존 트랜잭션의 운명에서 의도적으로 분리되는 선택”이라는 점과, 그만큼 강력하지만 위험한 옵션임을 실무 사례로 살펴봤습니다.그렇다면 전파 옵션 목록에 항상 함께 등장하지만실제 코드에서는 거의 보이지 않는이 옵션은 무엇일까요?NESTED이번 글에서는 NESTED가 무엇을 해결하려 했고, 왜 결과적으로 잘 쓰이지 않게 되었는지를 공식 문서 기준으로 정리해보겠습니다.1. NESTED의 기본 개념NESTED는 REQUIRED와 REQUIRES_NEW의 중간에 위치한 옵션처럼 보입니다.공식 문서에서 정의하는 NESTED의 의미는 다음과 같습니다.기존 트랜잭션이 있으면 그 안에 Savepoint를 만들고, 그 지점으로 롤백할 수 있게 한다즉,새 트랜잭션을 만들지 않고같은 트랜잭션..