ioh's Development

배타락을 걸었는데 다른 트랜잭션이 조회된다고

이커머스 프로젝트에서 재고 차감에 비관적 락을 적용하고 나서, 하나 궁금한 게 생겼다.배타락을 걸면 다른 트랜잭션이 이 데이터를 아예 못 읽나? 못 읽을 줄 알았다. 근데 읽힌다. 일반 SELECT는 배타락을 무시하고 데이터를 그냥 가져온다.공식 문서를 찾아봤는데 이렇게 적혀있다.Consistent reads ignore any locks set on the recordsthat exist in the read view.Consistent read는 읽기 뷰에 존재하는 레코드에 설정된 모든 잠금을 무시합니다.출처: MySQL 8.0 - InnoDB Locking ReadsConsistent read is the default mode in which InnoDB processesSELECT stateme..

Redis 분산락의 TTL이 만료됐는데, 트랜잭션이 아직 끝나지 않았다면

혹시 이런 상황, 생각해본 적 있으신가요?분산락을 공부하면 보통 이런 흐름으로 배운다."Redis에 Lock을 잡고 → 작업하고 → Lock을 해제한다"여기까지는 별로 어렵지 않다. 근데 공부하다가 문득 이런 생각이 들었다."Lock에 TTL이 5초인데... 내 트랜잭션이 6초 걸리면 어떻게 되지?" 처음엔 "설마 그런 일이 있겠어?" 하고 넘겼다. 근데 생각해보면 현실에서 충분히 일어날 수 있다. GC가 길어질 수도 있고, 네트워크가 느려질 수도 있고, 쿼리가 걸릴 수도 있다. 이 글은 그 "만약"이 실제로 터졌을 때 어떻게 대응할 수 있는지 정리한 내용이다.먼저, 문제 상황을 정확히 그려보자클라이언트 A Redis 클라이언트 B━━━━━━━━..

WIL - 4주차 (환경을 바꿀 수 없을 때, 나를 바꾸는 법)

이번 주에 새로 배운 것이상과 현실 사이에서 할 수 있는 건 생각보다 많다회사에서 새 프로젝트가 들어왔다. 보험 도메인이다. 처음 기획서를 받았을 때 정책이 빠져 있는 부분이 많았고, 고려사항도 불명확했다. 예전 같았으면 "기획이 덜 된 거 아닌가"라고 생각하고 기다렸을 것이다.이번엔 다르게 움직였다. AI를 활용해서 보험 도메인의 일반적인 정책, 예외 케이스, 고려해야 할 사항들을 먼저 정리했다. 다른 프로젝트에서 사람들이 어떤 부분을 놓쳤는지, 어떤 정책이 나중에 문제가 됐는지를 조사하고 참고했다. 그걸 바탕으로 기획 쪽에 질문을 던지고, 정책을 같이 구체화해나갔다.결과는 예상 밖이었다. 정책이 명확해지니 단순 CRUD는 물론이고, 복잡한 비즈니스 로직도 흐름이 보였다. 데드라인보다 빠르게 치고 나갈..