트랜잭션 롤백 시리즈
기획자분과 얘기를 하면서
캐시 충전을 하고 Key를 얻을 때 중간에 어떤 에러가 발생하면 어떻게 할지를 이야기했다.
이런 경우는 보통 트랜잭션을 롤백시키는 방식을 썼다.
근데, 혹시 롤백이 실패하거나 어떤 예외의 상황이 있을 수 있겠다는 생각을 했다.
그렇다면, Key에 스탬프를 찍는 방식으로 검증을 하면 어떨까 싶었다.
롤백이 실패할 수도 있을까?
트랜잭션 롤백은 체크 예외에서는 발생하지 않는다고 한다.
한번 실험을 해보자.
확인을 해봤다.
롤백이 됐어야 할 레코드가 롤백이 되지 않고 DB에 저장됐다..!
언체크 예외에서는 어떨까?
예외가 터지면 롤백이 돼서 DB에 저장되지 않았다.
DB의 내용을 다 지우고 다시 테스트를 해봤다.
이렇게 하면 예외가 터져도 롤백이 됐다.
왜 그런거야?
공식문서를 보면
The default behavior is as with EJB: rollback on unchecked exception (RuntimeException), assuming an unexpected outcome outside any business rules. Additionally, we also attempt to rollback on Error which is clearly an unexpected outcome as well.
언체크 예외는 비즈니스 규칙에서 벗어난 기대하지 않은 결과라고 가정하고 롤백을 한다. 예외도 마찬가지다.
By contrast, a checked exception is considered a business exception and therefore a regular expected outcome of the transactional business method, i.e. a kind of alternative return value which still allows for regular completion of resource operations.
하지만, 체크 예외는 비즈니스적인 예외고 트랜잭션에서 예측한 결과(의도한 로직)라고 할 수 있다. 그래서 롤백하지 않는다고 한다.
체크 예외에도 롤백을 하게 하려면
위처럼 어노테이션에 명시를 해주면 된다.
내부 메서드 호출도 롤백되지 않는다.
추가로
@Transactional가 적용된 메소드를 같은 클래스에서 호출해도 롤백이 안된다고 한다.
실제로 테스트를 해보니
언체크 예외를 던졌어도 트랜잭션이 롤백이 안 됐다.
