트랜잭션 격리수준 질문

애플리케이션 수준에서 Repeatable Read를 JPA는 항상 보장하는지 궁금합니다.

어떤 글에서는 DBMS의 격리수준 설정값에 따라 JPA도 동일한 격리수준 설정값을 갖는다고 하는데요.

대부분의 DBMS가 Read Commited라서 JPA도 ReadCommited인가보다 막연하게 생각했다가 아래 실습을 통해 큰 코를 다쳤습니다.

실습내용:
TX1에서 MEMBER(id=1, age=20) 인 DB레코드를 em.find(Member.class, 1L)로 조회해서 엔티티객체를 얻는다. 이후 sleep(15초)을 걸어준다.

TX2에서 h2-console에서 이 레코드를 업데이트 해서 age = 50 으로 변경하고 커밋을 한다.

그럼에도 불구하고 15초뒤 TX1에서 JPQL로 조회한 엔티티는 같은 주소값을 갖는 동일한 엔티티객체를 갖는다. 즉, age가 여전히 20이다.

어떻게 정리를 하는 것이 좋을까요?

DBMS설정값을 따른다 vs Repeatable Read

참고: https://cheese10yun.github.io/jpa-jpql/

안녕하세요, 인프런 AI 인턴입니다.

창신동 장첸님께서 질문해 주신 트랜잭션 격리 수준과 관련된 부분은 많은 사람들이 혼란을 겪는 주제 중 하나입니다. JPA의 영속성 컨텍스트는 데이터베이스와의 격리 수준과 독립적으로 항상 REPEATABLE READ 수준을 애플리케이션 차원에서 제공합니다. 이는 JPA의 1차 캐시 기능 덕분인데요, 트랜잭션 내에서는 동일한 엔티티를 반복해서 조회할 때 처음 조회한 시점의 데이터 상태가 유지되기 때문에 발생하는 현상입니다.

하지만 이와 독립적으로 데이터베이스 트랜잭션 격리 수준은 따로 설정되어 있어, 보통 READ COMMITTED로 설정되어 있습니다. 이는 JPA에서 데이터베이스와 상호작용할 때 사용하는 기본적인 동작으로, 영속성 컨텍스트에 의해 애플리케이션 레벨에서는 이러한 트랜잭션 격리 수준이 변경되지 않아도 높은 수준의 일관성을 제공합니다.

관련된 질문들과 답변 링크는 다음을 참고해 주세요:

1차 캐시와 트랜잭션 격리 수준: 이 게시물에서 JPA의 1차 캐시에 의해 REPEATABLE READ 수준이 어떻게 보장되는지가 잘 설명되어 있습니다.
트랜잭션 격리수준: REPEATABLE_READ 격리 수준이 애플리케이션 차원에서 보장되는 방식을 설명합니다.
DB격리레벨 강의자료중 궁금한점이 있습니다.: JPA가 DBMS의 격리 수준과 어떻게 상호작용하는지에 대한 설명을 제공합니다.

JPA의 1차 캐시는 동일한 엔티티를 조회할 때 데이터베이스의 상태 변경과 관계없이 트랜잭션 내에서 일관된 데이터를 제공하는 역할을 합니다. 그러나 트랜잭션 외에 데이터베이스 상태를 직접 수정하는 경우에는 주의가 필요합니다. 이와 관련된 동작이 실제 환경에서 기대했던 것과 다를 수 있으니 주의 깊게 확인하는 것이 좋습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변