낙관적 락 무한루프 도는 이유 공유합니다 !

MySQL을 사용한다면 Isolation Level이 REPEATABLE READ가 기본으로 설정되어 있는데요. 이 때 트랜잭션 안에서 처음 SELECT한 값은 트랜잭션이 끝나기 전까지 몇 번을 다시 SELECT해도 동일한 값으로 읽게 됩니다. 이것 때문에 문제가 발생하는데요...

트랜잭션 안에서 낙관적 락이 진행되도록 구현한 상황에서 쓰레드 100개가 동시에 재고를 감소 시키고, 업데이트에 성공하면 version을 1씩 증가시킨다고 해보겠습니다. DB에는 Stock이 100개 version이 1로 세팅되어 있다고 가정합니다.

@RequiredArgsConstructor
@Service
public class ProductService {
    private final ProductRepository productRepository;

    @Transactional
    public void subtractStockOptimistic(int productId, int quantity){
        int updatedCount = 0;
        while (updatedCount == 0){
            Product product = productRepository.findById(productId);
            product.subtractStock(quantity);
            updatedCount = productRepository.updateStockOptimistic(product);

            if (updatedCount <= 0) { //업데이트에 실패한 경우 50ms 대기
                try {
                    Thread.sleep(50);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

  <update id="updateStockOptimistic">
    update test_product
    set stock = #{stock}, version = version + 1
    where id = #{id}
      and version = #{version}
  </update>

쓰레드 100개는 처음에 재고를 읽어서 모두 다음 값을 받아옵니다.

stock : 100, version : 1

제일 빠른 트랜잭션이 업데이트를 성공하고 DB는 다음과 같이 변합니다.

stock: 99, version: 2

이제 나머지 99개의 트랜잭션은 version이 다르므로 모두 업데이트에 실패하게 됩니다.

업데이트에 실패하게 된 트랜잭션들은 재시도를 하게 됩니다.

이 때 DB에서 다시 읽어드린 재고는 stock: 99, version: 2일 것 같지만 실제로는

stock: 100, version: 1 를 읽게 됩니다.

왜냐하면 여전히 하나의 트랜잭션 안에 들어 있고, Isolation Level이 REPEATABLE READ로 처음 읽은 값을 계속 읽게 되기 때문입니다.

따라서 첫 트랜잭션을 제외한 모든 트랜잭션은 무한히 실패하게 됩니다.......

따라서 한 트랜잭션 안에서 업데이트와 재시도 로직이 진행되지 않도록 @Transactional을 메소드에서 떼주시면 정상 동작하게 됩니다.

혹시 정말 Isolation Level 때문인지 확인하고 싶으신 분들은 DB에 Isolation Level을 READ COMMITTED로 바꾸고 테스트를 진행해보시면 @Transactional이 붙어 있어도 정상 동작하는 것을 확인하실 수 있습니다~!