일이 처리 되기 위한 가장 작은 단위
commit 된 것만 read
insert, update, delete문과 같이 데이터을 요청하는 쿼리문이 날라오면 데이터베이스가 undo라는 이전 데이터를 가지고 있는 영역을 가지고 있음.
A가 commit을 해야 undo 영역에 데이터가 바뀜
B가 select를 하면 undo 영역의 데이터를 select 하는 것.
✅ read commit의 정합성 문제
select를 했는데 결과가 보이지 않는 것을 PHANTOM READ(데이터가 보였다가 안 보였다가 하는 것 = 유령 데이터) 라고 한다.
-> 해결하기 위해 repeatable read 사용
스프링에서, CRUD 중 C, U, D 는 데이터를 변경하기 때문에 commit이 필요하다. 따라서 트랜잭션을 위해 @Transactional 을 붙인다. 하지만 R(select)일 때는 트랜잭션을 붙이지 않는다.
🚫 주의
A(다른 트랜잭션)이 update 쿼리를 하더라도 같은 select 구문을 보장하지만, insert 쿼리를 할 때는 같은 select 를 보장하지 않는다.
즉, repeatable read가 변경은 처리할 수 있지만, insert는 처리하지 못한다. (팬텀을 막을 수 없다)
막기 위해서는 serializable 방식을 사용하여 완전 격리를 해야 한다. 하지만 serializable 을 사용하면 데이터베이스의 가용성이 떨어지고 동시처리가 안된다.
따라서 repeatable read를 사용하면서 하나의 트랜잭션에서 여러번 select(읽기)를 해야할 때는 팬텀 현상(유령 데이터)을 막으려면 테이블을 복제해서 읽는 등 다른 방식으로 해야한다.