PessimisticLock을 분산락으로 활용하는 질문에 대한 답변 남기겠습니다.

요니님 안녕하세요.
프로젝트의 규모가 생각보다 큰듯하여 파악을 먼저해본 후 답변을 다시 남기도록 하겠습니다.

감사합니다.

안녕하세요, 인프런 AI 인턴입니다.

요니님 질문에 답변 드리겠습니다.

Q1에 대하여:
PessimisticLock을 다른 Entity에 걸어 분산락으로 활용하는 것은 기술적으로 가능하겠으나, 설계상 몇 가지 고려해야 할 문제가 있습니다. 첫째, 동시성 이슈가 없는 Entity에 락을 건다면, 그 Entity의 처리가 병목이 되어 전체 시스템의 성능에 영향을 줄 수 있습니다. 두 번째로는 의도하지 않은 Deadlock 발생 가능성입니다. 트랜잭션이 다른 락을 기다리는 동안 발생할 수 있는 문제로, 복잡한 시스템에서 디버깅 및 유지보수를 어렵게 만듭니다. 또한, 분산 시스템의 경우 락을 걸고 관리하는 로직이 더욱 복잡하고 JPA가 지원하는 락 방법은 데이터베이스 세션에 국한되므로, 여러 데이터베이스 세션 또는 애플리케이션 인스턴스를 걸쳐 분산락을 유지 관리하기에는 적합하지 않을 수 있습니다.

Q2에 대하여:
트랜잭션이 커밋되거나 롤백될 때만 락이 반환되기 때문에 우선적으로 커밋을 해도, 해당 트랜잭션 내에서 락이 사용되는 로직이 완전히 완료되지 않으면 락이 해제되지 않을 수 있습니다. 테스트 실패의 원인은 락이 적절히 해제되지 않거나 코드 내의 다른 로직이 원하는 흐름으로 진행되지 않기 때문일 수 있습니다. 로그를 확인하거나 디버거를 사용해서 트랜잭션의 흐름을 단계별로 확인하여 문제를 진단하는 것이 필요합니다. 또한, 록이 설정되는 순서나 다른 트랜잭션이 락을 기다리는 방식에서 예상치 못한 문제가 발생하고 있을 가능성도 있습니다.

세세한 부분까지 살펴야 하는 문제이므로 Spring Data JDBC의 @Lock 어노테이션을 사용하는 방법이나 Spring Data JPA의 @Lock 사용 예제를 참고하시어 문제를 해결하는 데 도움이 될 수 있을 것입니다.

Spring Data JDBC - Reference Documentation v3.1.5의 JDBC Locking 절에서는 다음과 같이 설명하고 있습니다.
참고 문서

interface UserRepository extends CrudRepository<User, Long> {

@Lock(LockMode.PESSIMISTIC_READ)
List<User> findByLastname(String lastname);
}

그리고 Spring Data JPA의 Locking 절에서 제공된 예제는 다음과 같습니다.
참고 문서

interface UserRepository extends Repository<User, Long> {

@Lock(LockModeType.READ)
List<User> findByLastname(String lastname);
}

문서를 잘 살펴보시고 테스트 코드의 상황에 맞게 적용하시면 문제 해결에 도움이 될 것입니다.

감사합니다.