hyuko

생각 정리용 글. 어제 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..

이번 주 회고 — 요청 한 건의 여정생각 정리용으로 써두는 주간 회고. 이번 주는 따로따로 알던 개념들이 "요청 한 건이 들어와서 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 ..

지난 두 글에서 만든 그림 위에 가상 스레드를 한 줄 얹어 본다.첫 글 — Tomcat 의 max-threads=200 은 결국 OS 스레드 200개. 무한히 못 늘린다.두 번째 글 — @Transactional 은 connection 을 ThreadLocal 에 묶어서 트랜잭션 범위를 유지한다.이 두 그림의 전제가 "요청 = OS 스레드 하나" 라는 점. Java 21 Virtual Thread 는 바로 이 전제를 깬다. 그럼 위 두 글의 결론이 어떻게 바뀌고, 무엇은 그대로일까. 공식 문서 기준으로 정리.1. Virtual Thread 의 정체 — JEP 444 한 줄 요약Oracle Java 21 공식 문서:"A virtual thread isn't tied to a specific OS threa..