0. 들어가며

JPA를 활용하여 애플리케이션을 개발하다 보면 동시성 문제를 해결하기 위해 낙관적 락(Optimistic Lock)을 적용하는 경우가 있습니다. @Version 애노테이션을 사용하면 간단하게 해결되는 것처럼 보이지만, 흔히 낙관적 락을 "락을 걸지 않는다"고 표현하기 때문에 실제로 MySQL에서 어떻게 동작하는지 궁금해질 수 있습니다.

MySQL에서 UPDATE 문을 실행할 때는 반드시 락을 획득해야 하는데, 그렇다면 JPA의 낙관적 락은 어떻게 "락 없이" 동작하는 것일까요? 이에 대한 궁금증을 해결하기 위해 찾아본 내용을 정리해보았습니다.

결론적으로, JPA의 낙관적 락은 애플리케이션 차원에서 제공하는 충돌 감지 메커니즘이며, MySQL에서는 UPDATE 수행 시 실제로 락을 거는 것이 맞습니다.

1. MySQL의 동시성 제어

1.1 MySQL의 락(Lock)

MySQL은 여러 트랜잭션을 효율적으로 관리하기 위해 다양한 메커니즘을 제공합니다. 대표적인 방식은 다음과 같습니다.

• Row Lock (레코드 락) : 특정 레코드에 대한 읽기/쓰기 작업을 제한하는 방식
• Table Lock (테이블 락) : 테이블 전체에 대해 읽기/쓰기 작업을 제한하는 방식
• MVCC (Multi-Version Concurrency Control) : Undo Log를 활용하여 특정 시점의 데이터를 스냅샷처럼 관리하여 Repeatable Read를 보장하는 방식

이러한 물리적 락은 MySQL 엔진이 트랜잭션 운영 중 자동으로 설정하거나, 명시적으로 설정할 수도 있습니다. 핵심은 MySQL의 락은 DB 차원에서 직접적으로 동작한다는 점입니다.

1.2 MySQL UPDATE시 X-Lock

트랜잭션이 UPDATE 문을 실행하면 해당 레코드에 대해 X-Lock(Exclusive Lock)을 획득하게 됩니다. 이 락은 일반적으로 UPDATE 문이 종료될 때까지 유지되며, 트랜잭션이 종료되면 해제됩니다.