낙관적 , 비관적 락

• 각각 변경하고싶은게 다름
• 커넥션 순서에따라 데이터가 어떻게 될까?
• 일관성이 깨진다
• 이 문제를 해결하기 위한 것중 하나가 LOCK

결국 lock?

• 자물쇠를 걸고 푸는 행위가 lock
• 각 트랜잭션들을 어떻게 처리 할지 ? 격리수준을 어떻게 구현할지가
• lock

Lock 전략

낙관적 Lock

• 트랜잭션이 애초에 충돌이 발생하지 않는다 가정하고 사용하는 전략
• 충돌이 되면 그때서야 조취를 취함
• 애플리케이션 내에서 @Version이란 것을 통해서 구현하기 때문에
• 애플리케이션 락이라고 함

비관적 Lock

• 애초에 매번 충돌이 발생한다 가정하고 쓰이는 전략
• 데이터베이스 트랜잭션 Lock
• ex ) select for update
• 데이터 접근시 충돌할거같으니 바로 락을 검.

JPA 에선 어떻게 사용함?

낙관적락

• A가먼저 업데이트 버전값 update
• B는 버전이 안맞아서 수정 연산 안됨 나머지도 마찬가지.
• 낙관적락은 최초(커밋)요청이 발생하기 때문에? 동시성 테스트가 JVM에따라서
• 쿠폰의 갯수가 1~5개 만 발급함.
• 쿠폰 갯수가 5개 넘지않는걸 보장함

비관적 락

• 정확하게 5개 정확히 발급
• DB가 제공하는 락기능
• 공유락 / 베타락이 있음
• 데이터에 접근 할때부터 자물쇠를 잠그기 때문에
• 다시말하면 수정할 데이터를 조회할 때부터 먼저 락 거는 방법

• 20명의 사용자가 동시에 발급할경우 하나의 트랜잭션이 접근할 경우
• 트랜잭션이 끝난후 다음 트랜잭션이 시작됨
• 나머지는 쿠폰갯수가 0 이기 때문에 예외 발생

• 접근할 때 부터 락

정리

• 누가 더 좋다 없다
• 상황에 맞게 베스트 프렉틱스를 찾아야 됨

#########################

낙관적 락

비관적 락

• 비관적 락들의 옵션