하얀잔디

-> 특정 상황에 rollback 할지 말지를 정하는것. 대충 예상되는 에러에 대해선 롤백하기 싫을 경우 -> noRollbackFor.롤백 범위를 좀 넓히고 싶은경우 ( checked Exception 등 ) -> RollbackFor 이라고 생각하면 편함. ----- 이번엔 Spring에서 자주 놓치는 @Transactional의 다른 옵션들,특히 rollbackFor, noRollbackFor, readOnly에 대해 경험 기반으로 정리. 상황서비스 코드에서 try-catch로 감싼 로직이 있는데, 분명 예외가 발생했는데 DB에 insert된 데이터가 커밋됨.이유?Spring 트랜잭션은 기본적으로 RuntimeException 계열에서만 자동 롤백을 한다.즉, checked exception (..

예약 저장을 한다고 하자.예약 정보 DB 저장알림 테이블에 insert히스토리 로그 저장이 3가지가 동시에 일어나야 했다. 문제는, 알림 로직이 다른 서비스에서도 공통으로 쓰이다 보니@Transactional(propagation = REQUIRES_NEW)로 설정돼 있었던 것. ( 새로운 트랜잭션. 다른 트랜잭션 중단)문제 발생로그 저장 중 예외가 발생해서 전체 트랜잭션이 롤백되었는데알림은 DB에 남아 있었다...알고 보니, 알림 로직에 설정된 REQUIRES_NEW 때문에 별도 트랜잭션으로 commit 되어버린 것Spring Propagation 기본REQUIRED (기본값)기존 트랜잭션이 있으면 참여, 없으면 새로 만듦보통 대부분 이걸 씀 REQUIRES_NEW ** 체크**항상 새 트랜잭션을 만듦..