이 발표의 질문과 범위

이 발표를 들은 뒤, 문장 범위 행 락이 왜 이렇게 설계됐는지 — 어떤 대안을 재서 버렸고 어떤 근거로 성립하는지 — 를 말할 수 있다.

• 변경의 본체는 PR #7881 (CBRD-27034) — DELETE·UPDATE 의 행 락 보유를 커밋까지 → 문장 끝까지 로 줄이고, 행 락이 지키던 대기는 그 행을 쓴 트랜잭션의 락이 받는다. 미커밋 인스턴스 엔트리 150 → 1
• 조각마다 배경의 어느 사실에 기대는지 두 장의 표로 보인다 (12·13번) — 주장이 아니라 유도다
• 적용 범위 — 서버 질의 실행기가 실행하는, MVCC 클래스의, 온라인 인덱스 빌드 중이 아닌, READ COMMITTED 의, savepoint·DDL 을 지나지 않은 트랜잭션의 가장 바깥 문장. 숫자는 여기서만 성립한다

엄격한 2PL 이 요구하는 것은 성질이지 표현이 아니다

• 락이 막는 것은 하나다 — 미커밋 쓰기 위에 다른 쓰기가 올라가지 않는다 (lost update · dirty write)
• 엄격한 2PL 은 배타 락을 커밋까지 쥐라고 한다 — 연쇄 롤백을 끊기 위해서다
• MVCC 는 읽기를 락에서 풀지만 쓰기 충돌은 남긴다 — first-updater-wins 는 상대 트랜잭션의 결말을 기다린다
• 행 X 락 하나가 셋을 겸한다 — 충돌 검출 · 결말까지의 대기 · 롤백 보호
• "행마다 엔트리를 커밋까지" 는 그 성질의 한 표현이다 — 표현이 달라도 성질이 유지되면 규약은 지켜진다
• 락에는 두 축이 있다 — 획득 시점과 보유 기간. 이 변경은 보유 기간만 옮긴다

락 매니저는 자원의 이름을 모른다

• 락 테이블 = 자원 이름 → 요청 리스트의 해시, 그리고 트랜잭션이 쥔 것의 리스트 (교과서 구조 그대로)
• 자원은 이름이다 — 행도, 테이블도, 트랜잭션 식별자도 키가 되고 대기 큐·데드락 검출·해제가 따라온다
• 데드락 검출기는 락 매니저 안의 대기만 본다 — 래치 대기, 자체 스핀은 그래프에 없다
• 기아 방지(먼저 선 X 를 S 흐름이 앞지르지 못한다)도 락 큐 안의 대기에만 따라온다
• X 의 커밋까지 보유는 정책이다 — 락 매니저 안에 커밋 전 해제 경로가 이미 있다
• lock escalation 은 락 테이블의 메모리 밸브다 — 대가는 건드린 적 없는 행까지 막는 것

두 계열 — 소유는 레코드에, 대기는 트랜잭션에

• 레코드 표시 계열 — 소유는 레코드에, 대기 대상은 트랜잭션. lock escalation 할 대상이 없다
• 락 테이블 계열 — 행마다 엔트리, 대기 대상은 그 엔트리. 엔트리당 메모리가 큰 쪽은 lock escalation 을 둔다
• 락 테이블 계열 안에서도 두 이동 — InnoDB 는 보유 기간을 정책으로 다루고, SQL Server 는 대기 대상을 트랜잭션으로 옮겼다

같은 네 질문의 답이 엔진을 두 계열로 가른다

• 설계로 건너가는 원칙 넷 — 소유는 레코드에·대기는 트랜잭션에 / 트랜잭션 락은 기존 락 매니저의 자원으로 / 보유 기간은 정책 / lock escalation 은 락 테이블 계열의 증상

CUBRID — 락 테이블 계열이지만 소유 표시는 이미 두 곳에 있다

• LK_ENTRY 의 count 는 요청 수다 — 같은 행을 두 번 잡으면 엔트리 하나에 count 2, 획득과 해제는 1:1
• DELETE 는 두 단계다 — select 단계가 대상 OID 를 모으며 X 를 잡고, force 단계가 실제로 지우며 한 번 더 요청한다
• 그래서 지운 행 하나에 요청이 둘 붙는다 — 그리고 스캔은 자기가 DML 대상인지 FOR UPDATE 인지 모른다
• 문장은 겹친다 — MERGE 는 두 절을 각각 실행기 호출로 시스템 연산 안에서 돌린다
• lock escalation 은 인스턴스 엔트리를 회수하되 새 요청을 남기지 않고, 이후로는 엔트리를 만들지 않는다
• MVCC 스탬프(INSID·DELID)가 소유를 레코드에 이미 적는다 — 행 락은 그 중복 사본이다
• INSERT 는 이미 삽입자의 MVCCID 를 자원 이름으로 잡는 락(self-lock)을 쓴다 (CBRD-26942) — 이 설계는 그것을 삭제·갱신으로 넓힌다

대가는 보유량이 아니라 보유 기간이다

• 300행 중 150행을 건드린 미커밋 트랜잭션이 쥔 인스턴스 엔트리 150 — 커밋까지, 문장마다 누적
• select 단계가 끝난 시점에 삭제자는 후보 전부를 쥐고 지운 행은 0 — 그 앞의 대기는 아직 일어나지 않은 충돌이고, 그 간선이 사이클을 닫으면 충돌한 적 없이 abort 된다
• lock escalation 뒤에는 건드린 적 없는 행까지 — 읽기 약 21,300 req/s 가 200,000행 DELETE(끝내 ROLLBACK) 하나에 0 req/s 로 약 38초 — lock escalation 의 몫이라 이 변경 밖이다 (16번)

한 문장 설계 — 세 보장을 스탬프와 self-lock 으로 옮긴다

행 락이 지키던 자리를 행 헤더의 스탬프와 그 스탬프 주인의 MVCCID self-lock 이 대신 지키고, 행 락 자체는 문장이 끝날 때 반납한다.

• 두 번째 writer 가 실제로 기다리는 것은 행이 아니라 그 행을 쓴 트랜잭션의 결말이다 — 결말을 직접 기다릴 자리를 두고 우회로를 걷어낸다
• 새 발명이 아니다 — PostgreSQL·Oracle 이 운영하는 형태이고 CUBRID 의 INSERT 경로가 이미 같다. 획득 시점은 그대로, 보유 기간만 바뀐다

설계는 배경에서 유도된다 — 반납·self-lock·정착

• 사실이 정하지 않은 것은 셋 — 놓는 시점(게시 직후인가 문장 끝인가 → 17번의 측정이 정했다), self-lock 의 단위와 모드, 정착 대기를 쥔 채 하는가(그 대가가 재접촉이다)

설계는 배경에서 유도된다 — 셈·문장 경계·스캔·생략

• 네 조각은 전부 회계다 — 어느 락이 이 문장의 것인가. select 무락화를 미룬 대가로 이 설계가 그 질문을 스스로 답한다

새로 생기는 여섯 조각

• 코드는 이 발표 밖이다 — 표는 모듈 열까지만 보이고, 구현은 설계 독본의 모듈·구현 장에 있다

한 행이 겪는 순서 — self-lock 은 스탬프보다 먼저, 행 락보다 늦게

• 삭제자는 DELID 를 새기기 전에 자기 MVCCID 를 X 로 쥐고, 문장 끝에 행 락을 반납하고, 커밋에서 self-lock 을 놓는다
• 늦게 온 자는 행 X 를 먼저 잡고 헤더의 스탬프를 만나 주인의 self-lock 을 S 로 기다렸다 깨어나 다시 판정한다 — 대기자가 홀더가 된다
• 실패한 문장은 다르다 — 락은 커밋까지 쥐고 셈만 지운다

반납을 포기하는 다섯 자리, 그리고 lock escalation

• lock escalation 은 이 설계 밖이다 — 회수된 엔트리의 셈은 함께 사라지고, 클래스 락을 원래 모드로 내리는 층(강등)은 다음 PR (CBRD-27238) 이다

반납 시점은 문장 끝이다 — 게시 직후가 아닌 이유

• 게시 직후에 놓는 안 — "뒤에 온 자는 정착하므로 행 락은 할 일이 없다" 는 문장 이후의 writer 에는 맞고, 문장 도중의 writer 에는 틀리다
• 인덱스에서 옛 키에 삭제 스탬프를 찍고 새 키를 넣은 뒤 락을 놓으면, 그 락을 얻은 T2 가 힙 헤더로 판별하는데 힙의 최신 버전은 확정된 옛 값이라 통과한다 — 이미 지워진 인덱스 엔트리를 지우려다 죽는다

• 셋째 줄은 판별력이 없다 — 경합이 사라져 두 안이 같은 값을 낸다. 대조군 없이 봤다면 처방이 통했다고 잘못 읽었을 자리다

기각한 여섯 대안 — 근거는 측정이거나 논증이다

네 불변식 — 각각 논증과 검출기를 가진다

• 정확성 주장은 논증이 지고 실측은 반박하지 못했음을 말한다 — 이득 주장은 실측이 진다

효과 — 바뀌는 것, 바뀌지 않는 것, 나빠지는 것

• 바뀌지 않는 것 — 같은 행에 대한 대기 시간(대상이 행에서 트랜잭션으로 바뀔 뿐) · 획득 비용 · lock escalation 이 세운 클래스 락 · 트리거·뷰를 통한 문장 · RR 이상과 FOR UPDATE
• 나빠지는 것 — 재접촉 교착 둘이 남는다: ON DUPLICATE KEY UPDATE 의 충돌 행 fetch, SELECT … FOR UPDATE 로 자기 갱신 행을 다시 잡는 경로
• 그리고 진단 둘 — 타임아웃 메시지에서 행·테이블이 사라지고, lock_escalation 의 뜻이 "한 문장이 몇 행까지" 로 바뀐다
• 메모리와 종료 비용은 줄어드는 방향이지만 근거로 삼지 않는다 — lock escalation 이 상한을 이미 묶고 있다

검증 — 세 빌드, 두 축, 결과값 0

• 두 축 — results 는 0 이어야 하고 blocking 은 0 이 아니어야 한다. 154 시나리오, 트레이스 끔
• 발자국(cubrid lockdb 직접 계수)이 이 변경의 증거다 — 막힘 축이 아니다. 발자국과 시나리오가 함께 보지 않는 축(엔트리 하나 안의 회계)은 shell 스위트가 잡았다
• 트리거·뷰를 통한 DELETE·UPDATE 는 클라이언트 경로다 — 이 설계가 하나도 적용되지 않고 행 락 150 을 커밋까지 쥔다
• 이웃 — lock escalation 강등(다음 PR, CBRD-27238) · select 무락화(미룬 갈래, 획득 시점의 축) · 외래 키(완료 — 부모 행 락 0, 교착 12 → 1)