JPA 트랜잭션과 락

트랜잭션은 원자성, 일관성, 격리성, 지속성을 보장해야 한다. 원자성 : 트랜잭션내에서는 실행한 작업들은 마치 하나의 작업인 것 처럼 모두 성공하든가 모두 실패해야 한다. 일관성 : 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다. 격리성 : 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를들어 동시에 같은 데이터를 수정하지 못하도록해야 한다. 격리성과 관련된 성능 이슈로 인해 격리 수준을 선택할 수 있다. 지속성 : 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데이터베이스 로그 등을 사용해서 성공한 트랜잭션 내용을 복구해야 한다. 트랜잭션은 원자성, 일관성, 지속성을 보장한다. 문제를 격리성인데 트랜잭션 간에 격리성을 완벽히 보장하려면 트랜잭션을 거의 차례대로 실행해야 한다. 이렇게 하면 동시성 처리 성능이 매우 나빠진다. 트랜잭션 격리 수준은 다음과 같다.

• READ UNCOMMITTED (커밋되지 않는 읽기)
• READ COMMITTED (커밋된 읽기)
• REPEATABLE READ (반복 가능한 읽기)
• SERIALIZABLE (직렬화 기능)

순서대로 READ UNCOMMITTED가 격리 수준이 가장 낮고 SERIALIZABLE의 격리 수준이 가장 높다.

1. READ UNCOMMITTED : 커밋하지 않은 데이터를 읽을 수 있다. 예를 들어 트랜잭션1이 데이터를 수정하고 있는데 커밋하지 않아도 트랜잭션 2가 수정 중인 데이터를 조회 할 수 있다. 이것을 DIRTY READ라 한다. 트랜잭션 2가 DIRTY READ한 데이터를 사용하는데 트랜잭션 1을 롤백하면 데이터 정합성에 심각한 문제가 발생할 수 있다. DIRTY READ를 허용하는 격리 수준을 READ UNCOMMITTED라 한다.
2. READ COMMITTED : 커밋한 데이터만 읽을 수 있다. 따라서 DIRTY READ가 발생하지 않는다. 하자만 NON-REPEATABLE READ가 발생할 수 있다. 예를들어 트랜잭션 1이 회원 A를 조회 중인데 갑자기 트랜잭션 2가 회원 A를 수정하고 커밋하면 트랜잭션 1이 다시 회원 A를 조회했을 때 수정된 데이터가 조회된다. 이처럼 반복해서 같은 데이터를 읽을 수 없는 상태를 NON-REPEATABLE READ 라 한다. DIRTY READ는 허용하지 않지만 NON-REPEATABLE READ는 허용하는 격리 수준을 READ COMMITTED라 한다.
3. REPEATABLE READ : 한번 조회한 데이터를 반복해서 조회해도 같은 데이터가 조회된다. 하지만 REPEATABLE READ는 발생할 수 있다. 예를 들어 트랜잭션1이 10살 이하의 회원을 조회했는데 트랜잭션 2가 5살 회원을 추가하고 커밋하면 트랜잭션1이 다시 10살 이하의 회원을 조회했을 때 회원 하나가 추가된 상태로 조회된다. 이처럼 반복 조회시 결과 집합이 달라지는 것을 REPEATABLE READ라 한다. NON-REPEATABLE READ는 허용하지 않지만 REPEATABLE READ는 허용하는 격리 수준을 REPEATABLE READ라 한다.
4. SERIALIZABLE : 가장 엄격한 트랜잭션 격리 수준이다. 여기서는 REPEATABLE READ가 발생하지 않는다. 하지만 동시성 처리 성능이 급격히 떨어 질 수 있다.

애플리케이션 대부분은 동시성 처리가 중요하므로 데이터베이스들은 보통 READ COMMITTED 격리 수준을 기본으로 사용한다.

낙관적 락과 비관적 락

JPA의 영속성 컨텍스트를 적절히 활용하면 데이터베이스 트랜잭션이 READ COMMITTED 격리 수준이어도 애플리케이션 레벨에서 반복 가능한 읽기(REPEATABLE READ)가 가능하다. 물론 엔티티가 아닌 스칼라 값을 직접 조회하면 영속성 컨텍스트의 관리를 받지 못하므로 반복 가능한 읽기를 할 수 없다. 낙관적 락은 이름 그대로 트랜잭션 대부분은 충돌이 발생하지 않는다고 낙관적으로 가정하는 방법이다. 이것은 데이터베이스가 제공하는 락 기능을 사용하는 것이 아니라 JPA가 제공하는 버전 관리 기능을 사용한다. 쉽게 이야기해서 애플리케이션이 제공하는 락이다. 낙관적 락은 트랜잭션을 커밋하기 전까지 트랜잭션의 충돌을 알 수 없다는 특징이다. 비관적 락은 이름 그대로 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법이다. 이것은 데이터베이스가 제공하는 락 기능을 사용한다. 대표적으로 select for update 구문이 있다.

@Version

낙관적 락과 비관적 락을 설명하기 전에 먼저 @Version을 알아보자. JPA가 제공하는 낙관적 락을 사용하려면 @Version 어노테이션을 사용해서 버전 관리 기능을 추가해야 한다. @Version 적용 가능 타입은 다음과 같다. - Long (long) - Integer (int) - Short (short) - TimeStamp

@Entity
@Data
public class Board {

  @Id
  private Long id;

  private String title;

  @Version
  private Integer version;
}

@Version 어노테이션을 붙이면 엔티티가 수정될때 자동으로 버전이 하나씩 증가하게 된다. 엔티티를 수정할 때 조회 시점의 버전과 수정 시점의 버전이 다르면 예외가 발생한다. 예를 들어 트랜잭션 1이 조회한 엔티티를 수정하고 있는데 트랜잭션 2에서 같은 엔티티를 수정하고 커밋해서 버전이 증가해버리면 트랜잭션 1이 커밋할 때 버전 정보가 다르므로 예외가 발생한다.

public static void main(String[] args) {
  //엔티티 매니저 생성 (비용이 많이 안든다.)
  EntityManager entityManager = entityManagerFactory.createEntityManager();

  //트랜잭션 획득
  EntityTransaction transaction = entityManager.getTransaction();

  try {
    transaction.begin(); 
    //트랜잭션1 조회
    Board board = entityManager.find(Board.class, 1L);
    //트랜잭션 2에서 해당 게시물을 수정
    board.setTitle("aaa");
    //예외 발생 데이터베이스에는 version=2 엔티티의 version=1
    transaction.commit(); 
  } catch (Exception e) {
    System.out.println(e);
    transaction.rollback();
  } finally {
    entityManager.close();
  }

  entityManagerFactory.close();
}

제목이 A이고 버전이 1인 게시물이 있다고 가정하자. 트랜잭션 1은 이것을 제목 B로 변경하려고 조회했다. 이때 트랜잭션 2가 해당 데이터를 조회해서 제목을 C로 수정하고 커밋해서 버전정보가 2로 증가했다. 이후에 트랜잭션 1이 데이터를 제목 B로 변경하고 트랜잭션을 커밋하는 순간 엔티티를 조회할 때 버전과 데이터베이스의 버전이 다르므로 예외가 발생한다. 버전 정보를 사용하면 최초 커밋만 인정된다.

JPA 락

락은 다음 위치에 적용할 수 있다. 1. EntityManager.lock(), EntityManager.find(), EntityManager.refresh() 2. Query.setLockMode() (TypeQuery 포함) 3. NamedQuery Board board = em.find(Board.class, id, LockModeType.OPTIMISTIC); 위에 처럼 조회하면서 즉시 락을 걸 수도 있고 Board board = em.find(Board.class, id); ... em.lock(LockModeType.OPTIMISTIC); 이처럼 필요 할 때 락을 걸 수도 있다. JPA가 제공하는 락 옵션은 javax.persistence.LockModeType에 정의되어있다.

락 모드	타입	설명
낙관적 락	OPTIMISTIC	낙관적 락을 사용한다.
낙관적 락	OPTIMISTIC_FORCE_INCREMENT	낙관적락 + 버전정보를 강제로 증가한다.
비관적 락	PESSIMISTIC_READ	비관적 락, 읽기 락을 사용한다.
비관적 락	PESSIMISTIC_WRITE	비관적 락, 쓰기 락을 사용한다.
비관적 락	PESSIMISTIC_FORCE_INCREMENT	비관적락 + 버전정보를 강제로 증가한다.
기타	NONE	락을 걸지 않는다.
기타	READ	JPA 1.0 호환기능이다. OPTIMISTIC 같다
기타	WRITE	JPA 1.0 호환기능이다. OPTIMISTIC_FORCE_INCREMENT 같다

이것으로 JPA의 락에 대해서 알아 봤다. 나중에는 락 타입에 대해서 상세하게 알아보자. 출처 : 자바 ORM 표준 JPA 프로그래밍 (김영한)