\n\n이 글은 윤준성의 개발꼬맹이 시절, 혼자 노션에 공부하며 정리해둔 것 중 괜찮은 것을 추려올린 글입니다.\n기술블로그 글 기고 목적으로 작성되지 않아, 가독성이 좋지 않거나 알 수 없는 워딩이 있을 수 있습니다.
\n
직렬가능 스케쥴: 서로 영향을 주지 않는 직렬 스케쥴을 비직렬적으로 수행하겠다!
\n→ 동시성을 최대한 보장하면서도 직렬 스케쥴과 같은 결과를 얻을 수 있는 직렬 가능 스케쥴을 지향해야 함
\n→ 같은 데이터에 동시에 두 트랜잭션이 접근하는 경우의 수
\n→ T1은 무효가 된 데이터를 읽게 됨
\n:T1의 갱신한 값을 T2가 덮어써서 T1의 갱신이 손실됨
\n:T1이 x, y를 각각 갱신하는 사이에 T2가 값을 갱신하여, 어떤 값은 갱신 전의 값을, 다른 값은 갱신 후의 값을 읽어 데이터가 불일치 하는 현상
\n:Optimistic Lock(비선점 락? 낙관적 락?)과 Pessimistic Lock(선점 락? 비관적 락?)
\n:잠금의 대상이 되는 객체의 크기
\n:트랜잭션 대부분 충돌이 발생하지 않을 때 사용하는 방법
\n→ 자원을 선점하지 말자, 충돌이 일어날 때만 적절히 대응하자
\n→ 엔티티에 version을 담아두고, 수정할 때마다 version을 +1씩 업데이트 한다
\n→ 엔티티를 가져와서 값을 수정하고 다시 저장하려고 하는데 갖고 있는 version과 DB의 version이 다르면 rollback!
\n:트랜잭션이 데이터에 접근하는 동안 그 데이터를 선점
\n다시 공유락(LS, Shared Lock)과 배타락(LX, Exclusive Lock)으로 나뉨
\n공유락) T1이 X에 대해 공유락을 걸면
\n배타락) T1이 X에 대해 배타락을 걸면
\n: 트랜잭션들이 Lock하는 시간과 Unlock하는 시간을 구분하여 수행
\n→ 직렬 가능한 스케쥴을 항상 보장한다는 것에 의의가 있다
\n→ 연쇄 복귀 문제에 빠질 수 있다
\n→ 이는 모든 unlock연산을 트랜잭션이 완전히 완료된 후에 실행하도록 하는 엄격한 2단계 잠금(strict 2-Phase Locking Protocol)을 통해 해결 가능하다
\n