트랜잭션은 ACID를 보장해야 한다.

 

 

ACID 란?

 

  • Atomicity : 원자성
    • 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것 처럼 모두 성공하든가 모두 실패해야 한다.
  • Consistency : 일관성
    • 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 DB 에서 정해놓은 무결성 제약 조건을 항상 만족해야 한다. 또는 타입을 만족해야한다. (숫자컬럼에 문자열 값이 저장되어서는 안된다.)
  • Isolation : 격리성
    • 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록 해야 한다. 격리성은 동시성과 관련된 성능 이슈와 연관이 깊고, 우리는 격리 수준을 선택할 수 있다.
  • Durability : 지속성
    • 트랜잭션을 성공적으로 끝내면, 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데이터베이스 로그 등을 사용해서 성공한 트랜잭션 내용을 복구해야 한다.

 

트랜잭션은 원자성, 일관성, 지속성을 보장한다. 문제는 격리성인데 트랜잭션간에 격리성을 완정히 보장하려면 트랜잭션을 거의 차례대로 실행해야 한다. 그러나, 이렇게 하면 동시성 처리 성능이 매우 나빠진다. 이런 문제로 ANSI 표준은 트랜잭션 격리 수준을 4단계로 나누어 정의했다. 트랜잭션의 격리 수준은 다음과 같다.

 

 

ANSI 표준, 트랜잭션 격리 수준

 

  • READ UNCOMMITED (커밋되지 않은 읽기)
  • READ COMMITED (커밋된 읽기)
  • REPEATABLE READ (반복 가능한 읽기)
  • SERIALIZABLE (직렬화 가능)

여기서 READ UNCOMMITED 의 격리 수준이 가장 낮고 SERIALIZABLE 의 격리 수준이 가장 높다. 격리 수준이 낮을수록 동시성은 증가하고 성능은 더 증가하지만 다양한 문제가 발생한다. 먼저 각 격리 수준에 따라 읽을 수 있는 내용은 다음과 같다.

 

 

 

  • DIRTY READ
    • 한 트랜잭션 내부에서 커밋 하지 않은 데이터를 읽을 수 있음을 의미한다. 예를 들어 트랜잭션 1이 데이터를 수정하고 있는데 커밋하지 않아도 트랜잭션 2가 수정 중인 데이터를 조회할 수 있다. 만약 트랜잭션 2가 DIRTY READ 한 데이터를 수정 했는데 트랜잭션 1이 롤백을 해버리면 데이터 정합성에 심각한 문제가 발생할 수 있다.
    • 이런 읽기를 허용하는 격리 수준을 READ UNCOMMITED 라고 부른다.
  • NON-PEPEATABLE READ
    • 한 트랜잭션 내부에서는 커밋한 데이터만 읽을 수 있음을 의미한다. 따라서 DIRTY READ 가 발생하지 않는다. 그러나 반복 가능한 읽기를 지원하지 않는다. 예를 들어서 트랜잭션 1이 회원 A를 조회중인데 갑자기 트랜잭션 2가 회원 A를 수정하고 커밋하면 트랜잭션 1이 다시 회원 A를 조회했을 때 수정된 데이터가 조회된다. 이처럼 같은 데이터를 읽을 수 없는 상태를 NON-PEPEATABLE READ 하고 부른다.
    • 이를 허용하는 격리 수준을 READ COMMITED 라고 부른다. 보통의 DB 들의 격리 수준은 NON-PEPEATABLE READ 를 허용한다.
  • PHANTOM READ
    • 한 트랜젝션 내부에서 일정 범위의 데이터를 2번 조회할 때, 결과 집합이 달라질 수 있음을 의미한다. 예를 들어 트랜잭션 1이 10살 이하의 회원을 조회했는데 트랜잭션 2가 5살 회원을 추가하고 커밋하면 트랜잭션 1이 다시 10살 이하의 회원을 조회했을 때 회원이 하나 추가된 상태로 조회되는 것을 의미한다.
    • 이런 읽기를 허용하는 격리 수준은 REPEATABLE READ 이다.

위 모든 읽기를 허용하지 않는 상태가 SERIALIZABLE 이며 이는 동시성 처리 성능이 급격히 떨어질 수 있다.

한편, 보봉 DB의 격리 수준은 READ COMMITTED 이지만 더 높은 격리 수준이 필요하다면 낙관적 락과 비관적 락 중 하나를 사용할 수 있다.

 

READ COMMITTED 보다 더 높은 격리 수준

 

낙관적 락

트랜잭션 대부분은 충동이 발생하지 않는다고 낙관적으로 가정하고 접근하는 방식.

애플리케이션 단에서 Lock 을 건다. 즉, 읽을 때가 아니라, 수정 작업을 할 때 이 데이터가 읽었을 때와 달라진 데이터인지 확인을 하고 달라지지 않았다면 수정작업을 하고 달라졌다면 예외를 발생시킨다.

JPA 에서는 낙관적 락을 사용할 수 있도록 @Version 이라는 어노테이션을 지원하고 있다.

엔티티가 수정될때 마다 자동으로 버전을 증가 시키며, 커밋을 하기 전에 엔티티의 버전과 DB의 버전이 같은지 확인을 한다.

버전이 다르면 OptimisticLockException 을 발생 시킨다.

지원하는 타입은 long, Long int, Integer, short, Short, timestamp 이다.

@Version
private Integer version;
update {table}
set
  {column} = ?,
  version = ?     -- 버전증가
where
  id = ?
  and version = ? -- 버전비교

 

비관적 락

일단 트랜잭션 충돌이 발생할 것이라고 가정하고 우선 Lock을 거는 방법이다. 이는 데이터베이스가 제공하는 Lock 기능을 사용한다. 여기에는 읽기 잠금(공유 잠금)과 쓰기 잠금(베타적 잠금)이 있다.

  • 읽기 잠금 (공유 잠금)
    • 다른 트랜잭션이 데이터를 읽을 수는 있지만 쓰기는 할 수 없다.
  • 쓰기 잠금 (베타적 잠금)
    • 데이터를 변경할 때 Lock을 걸며 트랜잭션이 완료될때까지 유지되어 다른 트랜잭션은 해당 데이터에 접근할 수 없다.
저작자표시

티스토리툴바