-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
미해결
PessimisticLock 관련
24.05.10 00:43 작성 조회수 103
0
안녕하세요. 강의 잘 듣고 있습니다.
StockRepository 인터페이스에 PESSIMISTIC_WRITE 락을 걸고 테스트를 돌리면 잘 통과합니다.
다만, 궁금한 것은 쿼리를 보고 나서인데요,
예를 들어, thread-5가 SELECT 쿼리를 젤 먼저 날립니다. 그러면 thread-5가 락을 가지고 있는거겠죠? 이후 다른 스레드들도 모두 SELECT 쿼리만 날리게 됩니다.
제가 예상한 것은 thread-5가 UPDATE 쿼리를 날리고 메서드가 종료되면 COMMIT 되면서 락을 놓게 되고, 다른 스레드가 락을 가져가면서 또 UPDATE 쿼리를 날릴 수 있게 되는 것이였습니다.
하지만 제일 먼서 UPDATE 쿼리를 날린 것은 thread-5가 아니라 다른 스레드였는데요, 혹시 왜 그런 것인지 설명 가능하실까요?
답변을 작성해보세요.
1
최상용
지식공유자2024.05.19
쇼콜라끼삐또리님 안녕하세요.
답변이 늦어져서 죄송합니다.
제일 먼저 pessimistic lock 을 사용하여 쿼리를 날린 트랜잭션이 락을 소유하는 것이 맞습니다.
다만, 로깅시스템의 특성상 1번쿼리와 2번쿼리가 실행되었을 때 2번쿼리의 로깅이 먼저 찍힐 수 있습니다.
아마 겪고계신상황이 그런상황으로 생각됩니다.
감사합니다.
0
인프런 AI 인턴
2024.05.10
안녕하세요, 인프런 AI 인턴입니다.
쇼콜라끼삐또리님의 질문과 관련하여, PESSIMISTIC_WRITE 락과 관련된 처리 방식에 대해 알아보시면 도움이 될 것 같습니다. 일반적으로, PESSIMISTIC_WRITE 락은 동시에 여러 트랜잭션에서 같은 데이터에 대한 변경이 일어나는 것을 방지하기 위해 사용됩니다. 이 락 모드가 설정된 경우, 해당 데이터에 대해 업데이트(ex. UPDATE) 또는 삭제(DELETE)와 같은 작업을 시도하는 다른 트랜잭션은 락이 해제될 때까지 대기해야 합니다.
스레드들이 모두 SELECT 쿼리만 날린 후, UPDATE 쿼리를 날리는 스레드가 처음 SELECT 쿼리를 날린 스레드가 아닌 것을 보셨을 때, 여러 요인이 있을 수 있습니다. 이는 JPA의 락 메커니즘, 데이터베이스의 트랜잭션 격리 수준, 특정 스레드의 스케줄링, 트랜잭션의 시작과 종료 시점 등 다양한 요소에 의해 영향을 받을 수 있습니다.
더욱 구체적인 설명을 원하시면, 아래 링크의 질문과 답변을 참고하시기 바랍니다:
이 경우도 @Transactional 어노테이션과 함께 PESSIMISTIC_WRITE 락을 사용하면서 테스트 환경에서 발생한 동시성 관련 이슈에 대해 다루고 있습니다. 비록 직접적인 스레드 스케줄링이나 락의 획득 순서 변경에 대한 설명은 아니지만, 트랜잭션이 시작되고 끝나는 시점에 대한 이해를 돕는데 유용할 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 2