Spring 기초 Part 9: JPA 트랜잭션과 동시성 제어

Spring 기초 Part 9: JPA 트랜잭션과 동시성 제어

트랜잭션은 여러 데이터베이스 작업을 하나의 성공 또는 실패 단위로 묶는 것이다.

모든 작업이 성공하면 커밋하고, 중간에 실패하면 전체 작업을 롤백한다.

주문 생성
   ↓
재고 감소
   ↓
결제 정보 저장
   ↓
모두 성공 → COMMIT
하나라도 실패 → ROLLBACK

1. 먼저 알아둘 단어

2. ACID 원칙

3. @Transactional 동작 원리

@Transactional은 Spring이 트랜잭션 경계를 관리하도록 지정하는 어노테이션이다.

@Service
public class OrderService {

    @Transactional
    public void createOrder(Order order, Product product) {
        orderRepository.save(order);
        product.decreaseStock(1);
    }
}

Spring의 선언적 트랜잭션은 일반적으로 AOP Proxy를 통해 동작한다.

Transactional Proxy 실행 흐름

flowchart TD
    C[호출자] --> P[Transactional Proxy]
    P --> B[트랜잭션 시작]
    B --> S[실제 Service 메서드]
    S --> Q{정상 종료?}
    Q -->|예| F[flush]
    F --> COMMIT[commit]
    Q -->|롤백 대상 예외| ROLLBACK[rollback]

Proxy가 메서드 호출을 받음
          ↓
트랜잭션 시작
          ↓
실제 Service 메서드 실행
          ↓
정상 종료          롤백 대상 예외
   ↓                    ↓
COMMIT               ROLLBACK

같은 객체 안에서 this.method() 형태로 호출하면 Proxy를 거치지 않아 새 @Transactional 설정이 적용되지 않을 수 있다.

4. Service에 트랜잭션을 적용하는 이유

JpaRepository의 기본 저장, 수정, 삭제 메서드에도 트랜잭션이 적용되어 있다. save() 하나만 호출하는 작업은 자체 트랜잭션으로 실행될 수 있다.

하지만 하나의 비즈니스 작업은 여러 Repository 호출로 구성될 수 있다.

@Transactional
public void transfer(Long fromId, Long toId, int amount) {
    Account from = accountRepository.findById(fromId).orElseThrow();
    Account to = accountRepository.findById(toId).orElseThrow();

    from.withdraw(amount);
    to.deposit(amount);
}

출금과 입금은 함께 성공하거나 함께 실패해야 한다. 따라서 Repository 메서드 하나가 아니라 Service의 비즈니스 작업 전체를 트랜잭션으로 묶는다.

트랜잭션 경계는 데이터 접근 메서드 한 번이 아니라 하나의 완전한 업무 단위를 기준으로 잡는다.

5. 트랜잭션 범위는 짧게 유지한다

트랜잭션 안에서 외부 API나 파일 작업을 오래 수행하면 DB Connection과 Lock을 오랫동안 점유할 수 있다.

@Transactional
public void processOrder(Order order) {
    orderRepository.save(order);

    externalPaymentApi.call(); // 응답이 오래 걸릴 수 있음
    uploadReceiptFile();       // 파일 I/O
}

가능하면 DB 작업의 경계를 명확하게 분리한다.

DB 커밋과 외부 시스템 호출은 하나의 로컬 트랜잭션으로 원자적으로 묶이지 않는다. 실제 시스템에서는 재시도, 보상 처리, 이벤트, Outbox 패턴 등을 추가로 고려할 수 있다.

6. readOnly = true

클래스에 조회 전용 설정을 두고 쓰기 메서드에서 덮어쓸 수 있다.

@Service
@Transactional(readOnly = true)
public class UserService {

    public UserResponse getUser(Long id) {
        User user = userRepository.findById(id).orElseThrow();
        return UserResponse.from(user);
    }

    @Transactional
    public Long createUser(User user) {
        return userRepository.save(user).getId();
    }
}

readOnly = true는 조회 전용 의도를 표현하고 JPA 구현체나 DB 설정에 따라 flush와 변경 감지 비용을 줄이는 최적화에 활용될 수 있다.

모든 환경에서 쓰기 SQL을 완전히 차단하는 보안 장치는 아니다.

7. flush와 commit

Entity 변경
   ↓
flush
   ↓
UPDATE SQL 전달
   ↓
commit

flush가 실행된 뒤에도 commit 전에 오류가 발생하면 rollback할 수 있다.

8. 예외와 롤백 규칙

Spring의 @Transactional은 기본적으로 RuntimeException과 Error가 메서드 밖으로 전달될 때 롤백한다.

Checked Exception도 롤백하려면 rollbackFor를 지정한다.

@Transactional(rollbackFor = Exception.class)
public void process() throws MyCustomException {
    // DB 작업
}

특정 예외를 롤백 대상에서 제외할 수도 있다.

@Transactional(noRollbackFor = NotificationException.class)
public void process() {
    // DB 작업
}

예외를 메서드 안에서 잡으면

@Transactional
public void process() {
    try {
        orderRepository.save(order);
        paymentService.pay();
    } catch (RuntimeException exception) {
        // 예외를 다시 던지지 않음
    }
}

메서드가 정상 반환하면 Proxy는 예외가 발생했다는 사실을 알 수 없다. 롤백이 필요하다면 예외를 다시 던지거나 트랜잭션을 rollback-only 상태로 표시해야 한다.

9. 트랜잭션 전파

전파(Propagation)는 이미 트랜잭션이 있을 때 새로 호출된 메서드가 그 트랜잭션을 어떻게 사용할지 정하는 규칙이다.

REQUIRED

@Transactional
public void createOrder() {
    orderRepository.save(order);
    paymentService.pay();
}

paymentService.pay()도 REQUIRED라면 바깥 트랜잭션에 참여한다. 내부 작업이 rollback-only로 표시되면 최종 커밋 시 UnexpectedRollbackException이 발생할 수 있다.

REQUIRES_NEW

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveAuditLog(AuditLog log) {
    auditLogRepository.save(log);
}

새로운 물리 트랜잭션을 사용하므로 외부 트랜잭션과 독립적으로 커밋하거나 롤백할 수 있다.

다만 외부 트랜잭션의 자원은 유지한 채 새 DB Connection을 추가로 사용할 수 있다. 남발하면 Connection Pool 부족이나 Lock 대기가 발생할 수 있다.

또한 같은 객체의 내부 호출로는 전파 설정이 적용되지 않을 수 있으므로 별도 Bean을 통해 호출해야 한다.

10. 동시성 문제

@Transactional은 작업 범위를 묶어주지만 모든 동시성 문제를 자동으로 해결하지는 않는다.

11. 격리 수준

격리 수준은 다른 트랜잭션의 변경 내용을 어디까지 볼 수 있는지 정한다.

@Transactional(isolation = Isolation.READ_COMMITTED)
public void process() {
    // DB 작업
}

Spring의 Isolation.DEFAULT는 사용하는 DB의 기본 격리 수준을 따른다. 격리 수준을 높이면 정합성은 강해지지만 대기와 성능 비용이 증가할 수 있다.

12. 낙관적 락

낙관적 락은 충돌이 드물다고 가정하고 버전 값으로 수정 충돌을 감지한다.

@Entity
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private int stock;

    @Version
    private Long version;
}

JPA는 수정할 때 조회 당시 버전을 조건에 포함한다.

UPDATE product
SET stock = 9,
    version = 2
WHERE id = 1
  AND version = 1;

다른 트랜잭션이 먼저 수정해 버전이 달라졌다면 충돌 예외가 발생한다.

A와 B가 version = 1 조회
        ↓
A가 수정하고 version = 2로 커밋
        ↓
B가 version = 1 조건으로 수정
        ↓
수정 실패와 낙관적 락 예외

재시도할 때는 최신 데이터를 새 트랜잭션에서 다시 조회하고 업무 조건을 다시 검사해야 한다.

13. 비관적 락

비관적 락은 충돌이 자주 발생한다고 가정하고 조회 시점에 DB Lock을 획득한다.

public interface ProductRepository extends JpaRepository<Product, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select p from Product p where p.id = :id")
    Optional<Product> findByIdWithWriteLock(@Param("id") Long id);
}

@Transactional
public void decreaseStock(Long productId, int quantity) {
    Product product = productRepository
            .findByIdWithWriteLock(productId)
            .orElseThrow();

    product.decreaseStock(quantity);
}

Lock의 실제 동작은 DB 종류와 격리 수준에 따라 달라질 수 있다.

14. 해결 방법 선택

단순 재고 감소는 조건을 포함한 원자적 SQL로 처리할 수도 있다.

UPDATE product
SET stock = stock - 1
WHERE id = 1
  AND stock > 0;

수정된 행이 0개라면 재고가 없거나 상품이 없는 경우로 처리한다.

핵심 정리

@Transactional만 붙인다고 모든 문제가 해결되지는 않는다. 업무 단위, 롤백 규칙, 전파, 격리 수준과 동시성 제어 방법을 함께 선택해야 한다.

참고 자료

• Spring Framework 선언적 트랜잭션 공식 문서
• Spring Framework 트랜잭션 전파 공식 문서