트랜잭션과 락

트랜잭션과 격리 수준

• 트랜잭션은 ACID를 보장해야한다.
  • 원자성 : 모두 실패 또는 모두 성공
  • 일관성 : 일관성있는 상태 유지 → 무결성 조건 항상 만족
  • 격리성 : 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않도록 격리한다
  • 지속성 : 결과가 항상 기록되어야한다. → 복구를 위함
• 격리 수준(낮은 순으로) → 격리 수준이 낮을수록 동시성은 증가하지만 문제 발생

  • Read uncommited

    • 커밋하지 않은 데이터를 읽을 수 있다.
    • 트랜잭션1이 데이터를 수정하고 있는데 커밋하지 않아도 트랜잭션 2가 수정 중인 데이터를 조회할 수 있다.
    • 만일 트랜잭션2가 dirty read한 데이터를 사용하는 데 트랜잭션1을 롤백하면 데이터 정합성에 심각한 문제가 발생할 수 있다

  • Read commited → 보통 많이 쓰는 수준

    • 커밋한 데이터만 읽을 수 있다. 따라서 더티리드는 발생하지 않는다.
    • 트랜잭션1이 조회 중인데 갑자기 트랜잭션2가 이를 수정하고 커밋하면 트랜잭션1이 다시 조회시에 수정된 데이터가 조회된다. 이처럼 반복해서 같은 데이터를 읽을 수 없는 상태를 NON_REPEATABLE READ라고 한다.

  • Repeatable read

    • 한 번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회된다.
    • 트랜잭션1이 쿼리로 어떤 데이터 집합(목록)을 조회했을 때 트래잭션2가 이 집합에 해당하는 조건에 데이터(레코드)를 추가하고 커밋하면 트랜잭션1이 이를 재조회하면 데이터가 추가된 상태로 조회된다. 이처럼 반복 조회시 결과 집합이 달라지는 것을 PHANTOM READ라고 한다.

  • serializable

    • 가장 엄격한 격리 수준으로 PHANTOM READ가 발생하지 않지만 처리율이 급격히 떨어진다.

    

낙관적 락과 비관적 락 기초

• 낙관적 락
  • 트랜잭션 대부분은 충돌이 발생하지 않는다고 낙관적으로 가정하는 방법
  • DB가 제공하는 락 기능을 사용하는 것이 아닌 JPA가 제공하는 버전 관리 기능을 사용함 → 어플리케이션 수준에서 제공하는 락
  • 낙관적 락은 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알 수 없다는 특징이 있음
• 비관적 락
  • 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법
  • DB가 제공하는 락을 사용함
  • select for update
• 두 번의 갱신 분실 문제
  • 실제로 서로다른 사용자에 의한 두 번의 갱신이 발생해 첫 번째 갱신의 데이터가 소실되는 것
  • 해결 방법
    • 마지막 커밋만 인정
    • 최초 커밋만 인정
    • 충돌 부분 병함

@Version

• 엔티티의 버전 관리용 필드를 추가하고 해당 어노테이션을 붙여 관리
• 엔티티 수정시에 조회 시점의 버전과 수정 시점의 버전이 다르면 예외 발생

@Entity
public class Board {
	@Id
	private String id;
	private String title;

	@Version
	private Integer version;
}

• 버전정보비교 방법
  • JPA가 버전 정보를 비교하는 방식 → 엔티티를 수정하고 트랜잭션을 커밋하면 영속성 컨텍스트를 플러시 하면서 UPDATE 쿼리를 실행하는데 이때 버전 비교를 진행함.
  • 그리고 동시에 버전 필드의 값도 increase한다.

JPA 락 사용

JPA를 사용할때 추천하는 전략은 READ COMMITED + 낙관적 버전 관리

• JPA 낙관적 락

  • JPA가 제공하는 낙관적 락은 버전(@Version)을 사용한다. 따라서 낙관적 락을 사용하려면 버전이 있어야 한다. 낙관적 락은 트랜잭션을 커밋하는 시점에 충돌을 알 수 있다는 특징이 있다.

  • NONE

    • 락 옵션을 적용하지 않아도 엔티티에 @Version이 적용된 필드만 있으면 낙관적 락이 적용된다.
    • 용도 : 조회한 엔티티를 수정할때 다른 트랜잭션에 의해 변경되지 않아야한다. 조회 시점부터 수정시점까지를 보장
    • 동작 : 엔티티 수정시에 버전 관리
    • 이점 : 두 번의 갱신 분실 분제 예방

  • OPTIMISTIC

    • 엔티티를 조회만 해도 버전을 체크한다. 수정이 발생하지 않아도 체크
    • 용도 : 조회한 엔티티는 트랜잭션이 끝날 때까지 다른 트랜잭션에 의해 변경되지 않아야한다.
    • 동작 : 트랜잭션을 커밋할때 버전 정보를 조회해서 현재 엔티티의 버전과 같은지 검증한다.
    • 이점 : DIRTY CHECK, NON-REPEATABLE READ 방지

    

  • OPTIMISTIC_FORCE_INCREASE

    • 용도 : 연관관계에 있는 버전도 강제로 올릴때 사용
    • 동작 : 엔티티를 수정하지 않아도 트랜잭션을 커밋할때 UPDATE 쿼리를 사용해서 버전 정보를 강제로 증가시킨다. DB버전이 엔티티의 버전과 다르면 예외 발생. 추가로 엔티티를 수정하면 버전 UPDATE가 재 발생할 수 있음
    • 이점 : 강제로 버전을 증가해서 논리적인 단위의 엔티티 묶음을 버전 관리할 수 있다.

    OPTIMISTIC_FORCE_INCREMENT는 Aggregate Root(martinfowler.com/bliki/DDD_ Aggregate.html)에 사용할 수 있다. 예를 들어 Aggregate Root는 수정하지 않았지만 Aggregate Root가 관리하는 엔티티를 수정했을 때 Aggregate Root의 버전을 강제로 증가시킬 수 있다.