[트러블 슈팅] MySQL 환경에서 @QueryHint가 무시되어 timeout을 지정할 수 없는 문제 해결

2025. 7. 4. 22:56·트러블 슈팅

 

개요


스프링 데이터 JPA 환경에서 @Lock 애너테이션을 사용하여 비관적 락을 설정한 환경에서

비관적 락의 교착상태를 해결하기 위한 방법으로 최대 대기 시간을 지정해야 했습니다.

 

최대 대기 시간(timeout)을 지정하는 방법으로는 힌트를 사용했습니다.

public interface BookSeatRepository extends JpaRepository<BookSeat, BookSeatId> {
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @QueryHints({@QueryHint(name = "jakarta.persistence.lock.timeout", value = "1000")})
    @Query("select b from BookSeat b where b.seatId = :seatId and b.sessionId = :sessionId")
    Optional<BookSeat> findByIdWithLock(Long seatId, Long sessionId);

}

 

timeout을 설정하고 테스트 코드를 작성했을 때, 지정한 시간 이내에 잠금을 구하지 못하면 익셉션이 발생해야 했지만

익셉션이 발생하지 않는 문제가 발생했습니다.

 

문제의 원인을 한 줄로 소개해보자면 다음과 같습니다.

💡 MySQL환경을 포함한 특정 데이터베이스에서는 @QueryHint를 사용한 쿼리 단위 timeout 설정이 동작하지 않습니다.

 

이에 대한 문제점과 원인을 파악하고, 다른 방식으로 해결하는 방법을 다뤄보겠습니다.

 

개발 환경


hibernate : 6.6.4

spring boot : 3.4.1

spring data jpa : 3.4.1

spring-core : 6.2.1

mysql : 8.0.42

 

 

@QueryHint 어노테이션이 MySQL 환경에서 동작하는지 확인하기


@QueryHints({@QueryHint(name = "jakarta.persistence.lock.timeout", value = "1000")})

 

@QueryHint 어노테이션이 제대로 동작하면 DB의 타임아웃 시간을 설정하게 됩니다.

 

이 타임아웃이 제대로 동작한다면, PessimisticLockingFailureException 에러가 발생해야 합니다.

 

 

 

@QueryHint를 사용했을 때, 타임아웃이 제대로 동작하는지 테스트를 작성해 보았습니다.

 

테스트는 다음과 같이 동작합니다. 

1. A 스레드가 특정 행을 조회합니다.
2. A 스레드가 락을 얻고 나면 B스레드가 시작됩니다.
3. A 스레드는 락을 유지한 채로 10초 동안 대기합니다.
4. B 스레드는 동일한 행을 조회하여 락을 요청합니다.
5. B 스레드는 락 대기시간 초과로 인해 타임아웃 예외가 발생될 것을 기대합니다.

 

@Test
@DisplayName("비관적락 - 락 선점 시, 타임아웃으로 인한 예외 발생")
void 비관적락_타임아웃() throws InterruptedException{
    CountDownLatch latch = new CountDownLatch(1);
    ExecutorService executorService = Executors.newFixedThreadPool(2);
    AtomicReference<Throwable> error = new AtomicReference<>();

    // A 스레드
    executorService.submit(() -> {
        transactionTemplate.executeWithoutResult(status -> {
            try {
                bookSeatRepository.findByIdWithLock(1L, 1L);
                System.out.println("A: 락 획득");
                latch.countDown(); // 락을 획득했음을 B에게 알린다.
                Thread.sleep(10000); // 락 유지
                System.out.println("A: 작업 완료");
            } catch (Exception e) {
                System.out.println("A: 실패 - " + e.getClass().getName());
            }
        });
    });

    latch.await();
    // B 스레드: 락 걸린 상태에서 조회 시도
    Future<?> submit = executorService.submit(() -> {
        System.out.println("B: 조회 시도");
        transactionTemplate.executeWithoutResult(status -> {
            try {
                bookSeatRepository.findByIdWithLock(1L, 1L);
                System.out.println("B: 조회 성공");
            } catch (Exception e) {
                error.set(e);
                System.out.println("B: 조회 실패 - " + e.getClass().getName() + " - " + e.getMessage());
            }
        });
    });

    executorService.shutdown();
    executorService.awaitTermination(10, TimeUnit.SECONDS);

    Assertions.assertThat(error.get()).isInstanceOf(PessimisticLockingFailureException.class);
}

 

테스트 실패

 

테스트는 타임아웃 예외가 발생할 것이라는 예상과는 다르게 실패했습니다.

 

A스레드의 락이 10초의 대기시간 후에 반환되고, B스레드가 순차적으로 조회에 성공했습니다.

 

 

이유를 찾아보니


 

 

Hibernate의 공식 깃허브에 들어가 보니 MySQLDialect의 타임아웃 설정이 false로 되어 있었습니다.

hibernate

 

Handling Pessimistic Locking with JPA on Oracle, MySQL, PostgreSQL, Apache Derby and H2

또한 위의 블로그를 확인해 보면, MySQL은 query lock timeout을 지원하지 않는다고 합니다.

MySQL 뿐만 아니라 지원하지 않는 DB가 꽤 존재하는 걸 확인할 수 있습니다.

jpa pessimistic example

 

어떻게 해결할 수 있을까요?


테스트가 실패했다는 것은 대기 시간 설정이 없거나, A스레드가 대기했던 10초보다 긴 시간으로 설정되어 있을 것입니다.

 

테스트에서 사용하는 DB에 대기 시간을 확인하는 명령어를 사용하여 lock_wait_timeout을 확인해 보았습니다.

대기시간 확인

 

최대 대기 시간이 50초로 설정이 되어있습니다.

 

그 말은 50초의 대기시간을 갖고, 그 이후에 익셉션이 발생한다는 뜻입니다.

 

 

 

이 대기시간을 기존에 설정하려고 했던 3초로 변경해 보겠습니다. 

 

SET GLOBAL innodb_lock_wait_timeout = 3;

 

대기시간 3초

 

lock_wait_timeout을 변경하고, 위의 테스트를 다시 실행시켜 보았습니다.

테스트 성공

 

성공적으로 타임아웃이 동작하는 것을 확인할 수 있습니다.

 

A스레드가 락을 얻고 10초 대기하는 동안 B스레드가 실행되어 락을 얻으려고 합니다.

 

하지만 최대 대기 시간을 3초로 설정했기 때문에 B스레드에서 PessimisticLockingFailureException을 발생시킵니다.

 

 

참고


https://blog.mimacom.com/handling-pessimistic-locking-jpa-oracle-mysql-postgresql-derbi-h2/

 

https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core/src/main/java/org/hibernate/dialect/MySQLDialect.java

 

반응형

'트러블 슈팅' 카테고리의 다른 글

조회 성능 개선을 위한 쿼리 최적화 (1)  (0) 2025.08.19
[Redis] 캐싱을 사용하여 조회 성능 개선하기 (nGrinder)  (5) 2025.07.14
[트러블 슈팅] HikariCP 데드락 발생 원인과 해결 과정 (feat:nGrinder)  (1) 2025.03.22
[트러블 슈팅] JPA 성능 최적화: N+1 문제 해결 및 nGrinder를 사용한 성능 테스트  (0) 2025.03.15
'트러블 슈팅' 카테고리의 다른 글
  • 조회 성능 개선을 위한 쿼리 최적화 (1)
  • [Redis] 캐싱을 사용하여 조회 성능 개선하기 (nGrinder)
  • [트러블 슈팅] HikariCP 데드락 발생 원인과 해결 과정 (feat:nGrinder)
  • [트러블 슈팅] JPA 성능 최적화: N+1 문제 해결 및 nGrinder를 사용한 성능 테스트
taetae99
taetae99
우직하게 개발하기
    반응형
  • taetae99
    코드 대장간
    taetae99
  • 전체
    오늘
    어제
    • 분류 전체보기
      • Teck Stack
        • Java
        • Spring
        • DB
        • Redis
        • SpringSecurity
        • Docker
        • HTML
        • AWS
      • 우아한테크코스
      • CS & Architecture
        • DDD
        • CS
        • 디자인 패턴
      • 트러블 슈팅
      • 알고리즘
        • 프로그래머스
        • 백준
      • 프로젝트
        • Board 프로젝트
      • 기타
      • 대회 및 후기
  • 인기 글

  • hELLO· Designed By정상우.v4.10.3
taetae99
[트러블 슈팅] MySQL 환경에서 @QueryHint가 무시되어 timeout을 지정할 수 없는 문제 해결
상단으로

티스토리툴바