- 자원 요청에 따른 동시성문제가 발생할것이라고 예상하고 락을 걸어버림
- 하나의 트랜잭션이 접근하면 바로 락을 걸어서 다른 트랜잭션이 접근 못하게 막음
- 공유 락 혹은 배타락 두개가 존재하며 하나만 적용 가능
- 공유락은 다른 트랜잭션에서 읽기만 가능함
- 배타락은 읽기 쓰기 둘다 안됨
- 자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 함
- 충돌 예측하지않음
- 충돌이 나면 감지하고나서 처리
- 일반적으로 version 의 상태를 보고 충돌을 확인하며, 충돌이 확인된경우 롤백을 진행시킵니다. (hashcode나 timestamp를 이용해서 충돌을 확인할 수 도 있습니다.)
- DB단에서 동시성을 처리하는것이 아닌, 어플리케이션단에서 처리 합니다.
비관적락 - 데이터의 무결성이 중요한 부분, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는것이 예상되는 시나리오에서좋습니다. 낙관적락 - 실제로 데이터 충돌이 자주 일어나지 않을것이라고 예상되는 시나리오에서 좋습니다.
충돌이 많이 일어날 것인가 아닌가를 미리 판단하는 것은 어렵다고 판단. 그렇기에 초반엔 비관적락으로 모두 설정 후 나중에 충돌이 없는 경우만 판단하여 낙관적락으로 수정하는 수 밖에 없지않나?