[회고록] JPA와 MyBatis 혼용으로 발생한 HikariCP Deadlock 문제를 해결하며

정정일·2024년 12월 2일

2024년 초, 예상치 못한 문제와 마주한 사건이 있었습니다. (해당 글)
당시의 상황에 대한 회고록을 작성하려 합니다.

JPA와 MyBatis를 혼용한 코드에서 HikariCP Deadlock 문제가 발생했는데요.
몇 달간 문제없이 운영되던 코드였기에 더욱 당황스러웠습니다.

해결 과정에서 JPA, HikariCP, 그리고 영속성 컨텍스트의 동작 원리를 깊이 이해할 수 있었던 이 경험을 정리해보았습니다.

문제와의 첫 만남: 예상 밖의 Deadlock

📌 Slack 알림으로 시작된 문제

트래픽이 몰리는 시간, Slack에 아래와 같은 알림이 도착했습니다.

org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30008ms.

처음에는 제가 모르는 Connection Pool 관련 Exception으로 생각했습니다. 하지만 로그를 확인하며 문제의 심각성을 깨달았습니다.

HikariPool-1 - Timeout failure stats (total=40, active=40, idle=0, waiting=46)

HikariCP에서 maximum-pool-size로 설정된 40개의 Connection이 모두 점유된 상태였고, 대기 큐까지 꽉 차 있었습니다. 더욱 당황스러웠던 점은 이 로직이 몇 달 동안 잘 작동해왔다는 것입니다.

왜 갑자기 문제가 발생했을까?

첫 번째 의문은 "왜 지금 이 문제가 발생했는가?"였습니다.

설정 문제라면 이전에도 발생했어야 했습니다.
코드가 수정된 적이 없는데 문제가 생긴 이유는 무엇일까요?

이 의문은 문제를 해결하는 내내 저를 괴롭혔고, 결국 문제 해결의 중요한 단서가 되었습니다.

원인 분석: 의심과 확인의 반복

1. 재현 환경 구축: Local에서 재현

먼저 문제를 재현하기 위해 테스트 환경에서 maximum-pool-size를 1로 설정했습니다. 이로서 Exception 발생지점을 특정할 수 있었습니다.

public long findBy~~~() {
    return factory
        .select(serviceNotice.count())
        .from(serviceNotice)
        .where(
            serviceNotice.actType.eq("특정 조건"),
            serviceNotice.section.eq("특정 조건"),
            serviceNotice.actEnable.eq(true)
        )
        .fetchOne();
}

QueryDSL로 작성된 단순한 Select 쿼리였는데도 Connection이 반환되지 않고 점유 상태로 남아 있었습니다.

2. Connection Leak인가?

처음엔 Connection Leak을 의심했습니다.

"이 로직이 끝난 후 Connection을 반환하지 않는 이유는 무엇일까?"
"Connection 반환 로직이 누락되었을 가능성은 없을까?"

하지만 QueryDSL을 사용하는 코드 내부에서 명시적으로 Connection을 닫지 않아도 Connection이 자동으로 반환되어야 합니다. 관련 문서를 확인한 결과 OSIV(Open Session In View)와 관련된 문제일 가능성이 떠올랐습니다.

3. OSIV와 영속성 컨텍스트

OSIV는 웹 요청이 끝날 때까지 영속성 컨텍스트(EntityManager)를 유지합니다.
이는 Lazy Loading을 가능하게 하고, View 계층에서 데이터베이스와의 연동을 지원하지만, Connection 반환을 지연시키는 단점이 있습니다.

OSIV로 인해 트랜잭션이 끝난 뒤에도 Connection이 반환되지 않고 점유 상태로 남아 있었습니다.

4. OSIV와 상관없는 Deadlock? 트랜잭션 내부 혼용의 문제

문제를 더 깊이 조사한 결과, OSIV 설정 여부와 상관없이 동일 Transaction 내에서 JPA와 MyBatis를 혼용하면 Deadlock이 발생할 수 있다는 점을 확인했습니다.
동일 Transaction 내에서 JPA가 Connection을 점유한 상태로 MyBatis가 추가로 Connection을 요청했기 때문입니다.

@Transactional
public void problematicMethod() {
    jpaSelectMethod();      // Connection Pool에서 1개 점유
    mybatisSelectMethod();  // 추가 Connection 요청 -> Deadlock
}