In its default configuration, the Spring Framework’s transaction infrastructure code marks a transaction for rollback only in the case of runtime, unchecked exceptions. That is, when the thrown exception is an instance or subclass of RuntimeException. (Error instances also, by default, result in a rollback).
Checked exceptions that are thrown from a transactional method do not result in a rollback in the default configuration. You can configure exactly which Exception types mark a transaction for rollback, including checked exceptions by specifying rollback rules.
스프링 공식문서를 보면 unchecked 예외와 error가 발생했을 때는 자동ㅇ적으로 롤백이 되지만, checked 예외는 롤백이 자동으로 발생하지 않아서 추가 설정이 필요하다.
그렇다면 OOM같은 경우는 어떨까?
관련된 레퍼런스를 찾아보려고 해도 찾기가 어려웠다.
그렇다면, OOM이 발생했을 때는 어떤 상황이 되는지를 한번 봐보자.
이 내용을 보면 OOM이 발생했을 때 바로 JVM이 종료되지는 않는다.
OOM이 발생된 스레드를 종료시키고, 다른 스레드들은 정상적으로 작동한다. (그 스레드들이 OOM을 발생시키지 않는 이상)
모든 스레드가 종료되고, 데몬 스레드만 남았을 경우 JVM이 종료된다.
OOM은 왜 발생할까? JVM이 회수할 수 있는 메모리가 없기 때문이다. 다른 곳에서 모두 스여지고 있는 것이다.
"스프링은 error의 서브클래스에는 롤백을 하지 않는다"고 써있는데,스프링 공식문서에서는 error도 롤백이 디폴트로 된다고 써있다. 이 부분은 정확하지 않은듯하다.
다만, 여기서 중요한 통찰을 얻을 수 있다. OOM이 발생했을 때 이를 복구하려고 하면 다시 거기서 OOM이 발생할 수 있는 것이다.
OOM의 경우에는 한 스레드가 대부분의 메모리를 차지하고 있을 때, 다른 스레드가 메모리를 조금이라도 획득하려고 하면 OOM이 발생할 수 있다. 그런 상황을 말하는듯하다. 이렇게 OOM이 계속되면 트랜잭션은 타임아웃될 가능성이높다.
결국,
- 스프링에서는 에러 클래스도 디폴트로 롤백이 된다.
- 하지만, OOM이 발생했을 때 롤백이 될지 안될지는 알 수 없다. 안될 가능성이 높다
라고 결론을 내릴 수 있을 것 같다.
