[Spring Data JPA] Transaction 전파로 인한 DeadLock 발생과 해결

📖 목차

 

 

 

---

SpringBoot를 기반으로 이커머스 서비스를 구현하면서 동시성 이슈를 해결했다. 

 

[Spring & Spring Boot] - [Redis] Redisson을 이용한 분산 락 구현으로 동시성 이슈 해결

[Redis] Redisson을 이용한 분산 락 구현으로 동시성 이슈 해결

하지만, 동시성 이슈를 해결하는 과정에서 교착상태(DeadLock)가 발생했다.

 

데드락이 발생한 이유로는 savaAll을 사용해서 벌크로 데이터를 저장하거나

트랜잭션의 전파로 인한 상황 두 가지를 생각해 보았다.

 

 

 

 

 

 

 

📌  DeadLock이란?

  데드락(DeadLock)은 두 개 이상의 프로세스나 트랜잭션이 서로 상대방이 소유하고 있는 자원을 기다리며 무한 대기 상태에 빠지는 현상을 말한다. 즉, 각각의 프로세스나 트랜잭션이 필요한 자원을 다른 프로세스나 트랜잭션이 잠그고 있어서, 아무도 작업을 완료하지 못하고 멈춰버리는 상황이다.

 

 

 

 

 

📌  DeadLock이 발생하는 조건

• 상호 배제(Multual Exclusion) : 자원은 한 번에 하나의 프로세스만 사용할 수 있다.
• 점유와 대기(Hold and Wait) : 최소한 하나의 프로세스가 하나의 자원을 점유하고 있으며, 추가적인 자원을 요청하면서 대기 중이다.
• 비선점(No Preemption) : 자원이 선점될 수 없다. 즉, 프로세스가 자원을 자발적으로 놓지 않는 한, 다른 프로세스가 그 자원을 강제로 가져갈 수 없다.
• 순환 대기(Circular Wait) : 두 개 이상의 프로세스가 원형으로 자원을 대기하고 있다.

<순환 대기-Circular Wait>

 

이 그림을 설명하자면 다음과 같다.

1. 프로세스 P0는 자원 R0을 점유하고 있고, 자원 R1를 요청하고 있다.
2. 프로세스 P1는 자원 R1을 점유하고 있고, 자원 R2를 요청하고 있다.
3. 프로세스 P2는 자원 R2을 점유하고 있고, 자원 R3를 요청하고 있다.
4. 프로세스 P3는 자원 R3을 점유하고 있고, 자원 R0를 요청하고 있다.

  결국, 각 프로세스는 다른 프로세스가 점유한 자원을 요청하게 되어 원형으로 대기 상태에 빠지게 된다.

이로 인해 아무도 자원을 해제하지 못하고, 데드락 상태가 발생한다.

 

이 상태에서는 모든 프로세스가 서로의 자원을 기다리기 때문에, 어느 누구도 앞으로 나아가지 못하고 무한 대기에 빠진다.

 

 

 

 

 

📌  DeadLock 해결 방법

  DeadLock을 해결하기 위해 다음과 같은 방법을 생각해 볼 수 있다.

• 예방(Prevention) : 데드락의 네 가지 조건 중 하나를 제거하는 방식이다. 예를 들어, 자원 할당 순서를 정하거나, 한 번에 모든 자원을 요청하도록 하여 점유와 대기 조건을 제거할 수 있다.
• 회피(Avoidance) : 시스템이 데드락 상태에 빠지지 않도록 사전에 자원의 상태를 점검하여 안전 상태를 유지한다. 
• 탐지 및 복구(Detection and Recovery) : 데드락이 발생했음을 감지하고, 이를 해결하기 위해 프로세스를 종료하거나 자원을 선점하는 방식이다.
• 무시(Ignore) : 데드락이 드물게 발생하고 그 영향이 크지 않을 때는 데드락을 무시하는 방법도 있다. 대부분의 운영 체제는 이 방식을 사용한다.

 

 

 

 

✔️ 위의 방법들 중, 나는 '예방 및 회피' 방법을 채택하여 트랜잭션을 올바르게 관리해서 데드락 발생 가능성을 줄이고,
Redisson 라이브러리를 활용하여 동시성 제어를 구현했다.

 

 

 

 

 

📌  올바른 트랜잭션 적용 전

  'for문으로 'save' 메소드를 한번 씩 호출하는 것보다 데이터를 모아서 'saveAll' 로 저장하는 것이 어떨까?'라는 생각이 들었고,

테스트를 해보기 위해 'saveAll' 메소드를 호출했다. 

    @Transactional
    public void createHistory(
        Long orderId,
        List<OrderProduct> orderProducts
    ){
        OrderEntity orderEntity = orderRepository.findById(orderId)
            .orElseThrow(() -> new EntityNotFoundException(
                ExceptionMessage.ORDER_NOT_FOUND.toString()));

        List<HistoryEntity> entities = new ArrayList<>();
        for (OrderProduct dto : orderProducts) {
            ProductEntity productEntity = productRepository.findById(dto.getProductId())
                .orElseThrow(() -> new EntityNotFoundException(
                    ExceptionMessage.PRODUCT_NOT_FOUND.toString()));

            HistoryEntity historyEntity = HistoryEntity.builder()
                .order(orderEntity)
                .product(productEntity)
                .quantity(dto.getQuantity())
                .build();

//            historyRepository.save(historyEntity);
            entities.add(historyEntity);
        }
        
        historyRepository.saveAll(entities);
    }

 

 

  OrderService에서 HistoryService의 createHistory 메소드를 호출하고 있고,

createOrder와 createHistory 메소드에는 각각 트랜잭션이 걸려있다.

  @Transactional
  public OrderInfo createOrder(
        Long memberId,
        Long receiverId,
        Long totalAmount,
        PayType type,
        List<OrderProduct> orderProducts
    ) {
				...

        historyService.createHistory(saved.getId(), orderProducts);

        return ...
        ;
    }

<saveAll 메소드 호출 후, 동시성 테스트 진행중 발생한 오류>

 

  이 상태에서 동시성 테스트를 해본 결과 'Deadlock found when trying to get lock; try restarting transaction' 라는 오류가 발생한다. 그리고 'saveAll' 메소드를 사용할 경우 여러 엔티티에 대한 락을 동시에 걸기 때문에, 단일 엔티티를 저장하는 'save' 메소드를 사용하는 경우보다 더 많은 자원을 잠글 수 있어서 데드락 발생 가능성이 더 높아질 수 있다.

 

 

 

 

 

📌  올바른 트랜잭션 적용 후

  'saveAll' 메소드 대신 'save' 메소드를 호출하고, 한 트랜잭션에서 일어나야 하는 작업을 묶어보자.

 

createHistory와 createOrder는 한 트랜잭션에서 일어나야 하는 작업이다.

createHistory 메소드에 있는 @Transactional 어노테이션을 지워주면 해당 메소드는 트랜잭션 내에서 실행되지 않고, 호출된 메소드의 트랜잭션에 참여하게 된다. 따라서, createOrder 메소드가 시작한 트랜잭션에 createHistory 메소드가 참여하게 된다.

    // @Transactional
    public void createHistory(
        Long orderId,
        List<OrderProduct> orderProducts
    ){
        OrderEntity orderEntity = orderRepository.findById(orderId)
            .orElseThrow(() -> new EntityNotFoundException(
                ExceptionMessage.ORDER_NOT_FOUND.toString()));

//        List<HistoryEntity> entities = new ArrayList<>();
        for (OrderProduct dto : orderProducts) {
            ProductEntity productEntity = productRepository.findById(dto.getProductId())
                .orElseThrow(() -> new EntityNotFoundException(
                    ExceptionMessage.PRODUCT_NOT_FOUND.toString()));

            HistoryEntity historyEntity = HistoryEntity.builder()
                .order(orderEntity)
                .product(productEntity)
                .quantity(dto.getQuantity())
                .build();

            historyRepository.save(historyEntity);
//            entities.add(historyEntity);
        }
        
//        historyRepository.saveAll(entities);
    }

 

 

  @Transactional 어노테이션을 createOrder에만 적용해서 트랜잭션의 경계를 다시 설정해 준다.

  @Transactional
  public OrderInfo createOrder(
        Long memberId,
        Long receiverId,
        Long totalAmount,
        PayType type,
        List<OrderProduct> orderProducts
    ) {
				...

        historyService.createHistory(saved.getId(), orderProducts);

        return ...
        ;
    }

 

  위와 같이 createHistory 메소드에서 @Transactional 어노테이션이 제거되면, 해당 메소드는 트랜잭션 경계 내에서 실행되지 않는다. 따라서, 호출된 createOrder 메소드의 트랜잭션 내에서 실행된다. 이 경우에는 createOrder와 createHistory가 하나의 트랜잭션 내에서 실행되므로, createOrder 트랜잭션 내에서 롤백이 발생하면 createHistory의 작업도 롤백된다.

 

  적용 후, 똑같은 테스트 환경에서 데드락은 발생하지 않고 정상적으로 쿼리가 생성되는 것을 볼 수 있다.

<정상적으로 주문 쿼리가 생성되는 것을 확인할 수 있다.>

 

 

 

 

 

여기까지 데드락이 발생했을 때 해결방법에 대해 알아보았다.