hyuko

이번 주 한 줄 — 추상에서 구체로, 그 다음 대응으로지난주가 "트랜잭션이 connection 을 어떻게 잡고, 어떻게 겹치나(propagation)" 였다. 이번 주는 거기서 자연스럽게 떨어진 질문 세 개를 사흘에 걸쳐 한 단계씩 내려갔다.그 트랜잭션들이 동시에 돌 때 서로 뭘 보나? → 격리수준그 격리수준은 뭘로 구현되나? → record / gap / next-key lock그 락들이 엇갈려 물리면? → 데드락, 그리고 우리 코드가 받아내는 법추상(격리수준) → 구체(락) → 실전(데드락) → 대응(재시도)로 내려간 게 이번 주의 흐름. 각 글이 전날 글에서 연역됐다는 느낌이 강했다. 따로 외운 게 없었다.학습 회고 — InnoDB 동시성 3부작화 — 격리수준은 결국 락으로 구현된다가장 크게 풀린 ..

생각 정리용 글. 어제 글 결론이 "데드락은 막는 게 아니라 다루는 것. 재시도가 정답" 이었다. 그 "재시도" 라는 답을 좀 더 내려보면 두 가지 질문이 남는다.데드락 말고도 락에 막혀 트랜잭션이 죽는 또 다른 케이스(innodb_lock_wait_timeout)가 있는데, 둘의 동작이 어떻게 다른가Spring 쪽에서는 그 예외를 어떻게 잡아 재시도하고, 재시도의 전제인 멱등성은 어떻게 보장하나오늘은 이 두 줄기를 한 번에 정리.1. 락이 막혀 죽는 두 가지 모드(A) 데드락 — 즉시 감지 후 죽임어제 본 내용. 사이클이 생기는 순간 InnoDB 가 감지해 작은 쪽을 victim 으로 죽인다.ERROR 1213 (40001): Deadlock found when trying to get lock; tr..

생각 정리용 글. 어제 record / gap / next-key lock 을 정리했는데, 그 락들이 서로 엇갈려 물리면 데드락이다. 오늘은 데드락을 직접 재현해 보고, SHOW ENGINE INNODB STATUS 출력에서 범인을 읽는 법까지. 어제 본 "gap lock 끼리는 공존한다", "인덱스 없으면 락 범위가 폭발한다" 가 그대로 데드락의 원인으로 이어진다.공식 정의부터:"A deadlock is a situation in which multiple transactions are unable to proceed because each transaction holds a lock that is needed by another one."서로가 서로의 락을 기다리니 아무도 못 나아가는 상태. Inno..

생각 정리용 글. 지난주 시리즈에서 @Transactional 의 propagation(트랜잭션이 겹칠 때 어떻게 묶이나)까지 봤다. 그 다음 자연스러운 질문 — "그래서 그 트랜잭션이 다른 트랜잭션과 동시에 돌 때, 서로 뭘 보고 뭘 못 보나". 이게 격리수준(isolation level)이고, 결국 락(lock)으로 구현된다. 이번엔 MySQL InnoDB 기준으로 격리수준 4단계와 그걸 떠받치는 락 종류를 공식 문서로 정리.먼저 지난주와 이어지는 한 줄 — Spring 의 @Transactional(isolation = ...) 은 새 트랜잭션이 시작될 때만(propagation REQUIRED/REQUIRES_NEW) 적용된다. 기존 트랜잭션에 참여하면 무시되고 그쪽 격리수준을 따른다. 그러니 p..