hyuko

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

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

이번 주 회고 — 요청 한 건의 여정생각 정리용으로 써두는 주간 회고. 이번 주는 따로따로 알던 개념들이 "요청 한 건이 들어와서 DB 까지 갔다 오는 동안 무슨 일이 일어나는가" 라는 한 줄기로 꿰어진 주였다. 월요일에 받은 두 질문에서 시작해서, 거기 가지를 치다 보니 자연스럽게 블로그 4편이 됐다. 한 편씩 보면 별개 주제인데, 모아 놓으니 같은 여정의 다른 구간이더라.요일별 짧게월 (5/18): 두 질문 받음 — ① Python/Java 서버는 thread·process 를 어떻게 관리하나, OS 와 1:1 인가 ② JdbcTemplate·MyBatis 는 DB 와 어떻게 연결하나, HikariCP 란.화 (5/19): 두 질문을 "요청 한 건의 여정" 한 흐름으로 묶어 정리. 블로그 2편 발행 ..

조용히 어긋나는 세 지점생각 정리용 글. 지난 글들에서 정리한 두 가지 기둥 위에 얹는다.@Transactional 은 AOP proxy 가 가로채서, connection 을 ThreadLocal 에 묶는다.HikariCP 는 connection 을 풀에 미리 만들어 두고 빌려준다.이번엔 에러도 안 내고 조용히 어긋나는 세 지점을 본다. 셋 다 컴파일도 되고 평소엔 멀쩡히 도는데, 특정 조건에서 소리 없이 의도와 다르게 동작한다.propagation 을 오해해서 — 롤백이 안 굴러온다self-invocation 으로 — @Transactional 이 통째로 무시된다maxLifetime 을 안 맞춰서 — 죽은 connection 을 빌려준다1. propagation — ThreadLocal binding ..