지인과 이야기를 나누던중 JPA와 함께 MySQL에서 락을 사용할 때 커스텀 락을 사용하면 좋다는 이야기가 나왔다.

그 이유로 JPA에서 제공하는 락은 타임아웃이 짧아서, 예외가 발생할 확률이 높아지기 떄문이라고 들었다. 우선 실제로 타임아웃이 얼마나 되는지 알아보기전에 커스텀 락을 어떻게 구현하는지 궁금해졌다.

MySQL을 이용한 분산락으로 여러 서버에 걸친 동시성 관리 | 우아한형제들 기술블로그

이글을 보여주면서, User Level Lock을 사용해 커스텀 락을 만들어 쓰면 REPEATABLE READ에서 문제가 발생한다는 이야기를했다. REPEATABLE READ일때 Select … for update 를 걸어도 락은 걸지 않은 측에서는 Entity가 락에 걸리지 않고 바로 조회가 된다는 의미이다.

그런데 이 방식처럼 user level lock을 사용하면 트랜잭션을 사용하지 않고, 락을 거는 것이 가능하다. 왜 트랜잭션을 사용하지 않을까? 트랜잭션을 사용하면 커넥션 풀을 계속 잡고 있기 떄문에, 사용량이 많아지면 커넥션이 꽉찰 수 있기 떄문이다.