프로젝트를 하면서 동시성 문제가 무엇인지는 대충 알았어도 적용을하고, 고려하며 코드를 짜본 적은 없다.
그래서 간단하게나마 알아보려고한다!
트랜잭션 격리수준
동시에 여러 트랜잭션을 처리할 때, 해당 트랜잭션이 다른 트랜잭션에서 변경한 데이터를 볼 수 있는 기준을 결정하는 것이다.
격리수준은 크게 4가지로 나뉜다.
READ UNCOMMITTED (커밋되지 않은 읽기)
READ COMMITTED (커밋된 읽기)
REPEATABLE READ (반복 가능한 읽기)
SERIALIZABLE (직렬화 가능)
READ UNCOMMITTED (커밋되지 않은 읽기)
COMMIT이나 ROLLBACK 여부와 상관 없이 다른 트랜잭션에서 보여지게 된다.
이 때 다른 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있게 되는 현상을 더티리드 라고한다.
READ COMMITTED (커밋된 읽기)
COMMIT이 완료된 데이터만 다른 트랜잭션에서 조회할 수 있다.
하나의 트랜잭션 내에서 동일한 SELECT 쿼리를 실행했을 때 항상 같은 결과를 보장해야 한다는 NON-REPEATABLE READ 발생
REPEATABLE READ (반복 가능한 읽기)
다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 Phantom Read 가 발생한다.
SERIALIZABLE (직렬화 가능)
모든 트랜잭션을 순서대로 실행한다.
동시 처리가 거의 불가능하므로 사용을 권장하지 않는다.
@Transactional의 기본 격리 수준은
REPEATABLE READ라고한다!
JPA를 사용하면 READ COMMIT 이상의 격리 수준이 필요할 때에는 비관적 락(Pessimistic Lock) 과 낙관적 락(Optimistic Lock) 을 골라서 사용해야한다.
비관적 락(Pessimistic Lock)
트랜잭션이 충돌한다고 가정하고 락을 건다.
DB 가 제공하는 락 기능을 사용한다.
데이터를 수정 시 즉시 트랜잭션 충돌을 알 수 있다.
낙관적 락(Optimistic Lock)
트랜잭션이 충돌하지 않는다고 가정한다.
DB 가 제공하는 락 기능을 사용하지 않고 JPA 가 제공하는 버전 관리 기능을 사용한다.
특징으로는 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알 수 없다.
비관적 락을 사용하는 방법은 간단하다.
비관적 락의 종류는 세 가지로 나뉘어진다.
