코드 땜장이

공유 락과 배타 락의 차이: 읽기와 쓰기를 어떻게 막고 기다리게 할까 빠른 답 공유 락은 읽은 행을 보호하는 락에 가깝고, 같은 행에 대한 다른 공유 락은 허용하지만 배타 락은 기다리게 합니다. 배타 락은 변경할 행을 독점하는 락에 가깝고, 같은 행에 대한 공유 락과 배타 락 요청을 모두 기다리게 합니다. 일반 SELECT 와 SELECT ... FOR SHARE , SELECT ... FOR UPDATE 는 다릅니다. InnoDB의 일반 조회는 보통 MVCC 스냅샷을 읽고 행 락을 잡지 않습니다. 데드락은 두 트랜잭션이 서로 필요한 락을 이미 상대가 쥐고 있을 때 발생하며, DB가 한쪽을 롤백할 수 있습니다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 공유 락과 배타 락이 헷갈리는가 예제 쿼리와 결과 해석 실행 계획과 인덱스가 락 범위를 바꾼다 대기 시간을 짧게 보고 실패 처리하기 데드락은 어떤 순서에서 발생하는가 락 대기와 데드락 출력 예시 해석하기 버전 기준과 오래된 설명 차이 한눈에 비교 목적 공유 락은 읽은 데이터가 트랜잭션 도중 바뀌지 않게 보호하는 쪽에 가깝고, 배타 락은 변경 대상 행을 독점하는 쪽에 가깝습니다. 호환성 공유 락끼리는 함께 잡을 수 있지만, 공유 락과 배타 락은 서로 충돌합니다. 배타 락끼리도 충돌합니다. 대표 문법 MySQL InnoDB에서는 SELECT ... FOR SHARE 가 공유 락 기반의 락킹 읽기이고, SELECT ... FOR UPDATE 가 배타 락 기반의 락킹 읽기에 가깝습니다. 일반 조회와의 차이 일반 SELECT 는 보통 consistent read로 처리되어 행 락을 잡지 않습니다. 락을 동반한 읽기가 필요할 때 FOR SHARE 나 FOR UPDATE 를 명시합니다. 인덱스 영향 락은 WHERE 조건 자체보다 실행 계획상 스캔한 인덱스 레코드와 범위에 더 가깝게 걸립니다. 장애 양상 단순 경합은 락 대기로 나타나고, 순환 대기는 데드락으로 감지되어 한쪽 트랜잭션이 실패할 수 있습니다. ...

트랜잭션 격리 수준, 동시성과 정합성 사이에서 어떻게 선택할까 빠른 답 트랜잭션 격리 수준은 동시에 실행되는 트랜잭션이 서로의 변경을 어디까지 볼 수 있는지 정하는 설정이다. READ COMMITTED 는 Dirty Read를 막지만, 같은 트랜잭션 안에서 같은 행을 다시 읽었을 때 값이 달라질 수 있다. REPEATABLE READ 와 SERIALIZABLE 은 더 강한 일관성을 제공하지만, DBMS의 MVCC, 락, 인덱스 상태에 따라 성능 영향이 달라진다. 격리 수준은 이름만으로 고르기보다 쿼리 패턴, 트랜잭션 길이, 인덱스, 락 대기 상황을 함께 보고 결정해야 한다. 목차 한눈에 비교 왜 격리 수준은 이름만 외우면 헷갈릴까 선택 기준 매트릭스 세 가지 읽기 이상 현상 예제 테이블과 인덱스 트랜잭션 재현 SQL 실행 계획과 결과 해석 락 대기와 운영 출력 예시 애플리케이션 코드에서의 보완 흔한 오해 한눈에 비교 읽기 기준 READ UNCOMMITTED 는 커밋 전 변경까지 읽을 수 있고, READ COMMITTED 부터는 커밋된 데이터만 읽는다. 반복 조회 READ COMMITTED 에서는 같은 행을 다시 읽을 때 값이 바뀔 수 있고, REPEATABLE READ 는 같은 트랜잭션 안의 반복 읽기를 더 강하게 보장한다. 범위 조회 Phantom Read는 같은 조건으로 다시 조회했을 때 행의 개수나 집합이 달라지는 현상이며, DBMS의 MVCC와 범위 락 구현에 따라 관찰 결과가 달라진다. 동시성 비용 격리 수준이 높아질수록 일관성은 강해질 수 있지만 락 대기, 충돌, 재시도 비용이 늘 수 있다. 선택 기준 단순 조회인지, 결제·재고·계좌처럼 경쟁 상태를 막아야 하는 쓰기인지에 따라 격리 수준과 잠금 전략을 함께 봐야 한다. 왜 격리 수준은 이름만 외우면 헷갈릴까 트랜잭션 격리 수준은 동시에 여러 트랜잭션이 실행될 때 한 트랜잭션이 다른 트랜잭션의 변경을 어떻게 관찰할지 정한다. 낮은 격리 수준은 동시 처리에는 유리할 수 있지만 아직 ...

JPA EntityManager란 무엇인가: 영속성 컨텍스트와 엔티티 상태를 실무 흐름으로 이해하기 빠른 답 EntityManager의 핵심 역할은 DB에 바로 쓰는 것이 아니라 영속성 컨텍스트를 통해 엔티티 상태를 관리하는 데 있다. persist를 호출해도 INSERT가 즉시 나가지 않을 수 있으며, 실제 SQL 시점은 flush와 commit에 달려 있다. 1차 캐시와 변경 감지는 영속 상태의 엔티티에서만 기대한 대로 동작한다. merge, detach, clear를 무심코 쓰면 예상하지 못한 UPDATE 누락이나 중복 조회가 생길 수 있다. 목차 흐름으로 보기 왜 EntityManager를 영속성 컨텍스트로 이해해야 할까 영속성 컨텍스트와 EntityManager는 어떤 관계일까 엔티티 상태는 어떻게 바뀔까 Spring Boot에서 EntityManager와 트랜잭션은 어떻게 묶일까 persist, find, detach, remove, flush를 코드로 따라가 보기 merge가 특히 헷갈리는 이유 SQL 로그로 보면 동작이 더 선명해진다 실무에서 자주 놓치는 주의점 흐름으로 보기 실무에서는 이 여섯 단계를 머릿속에 두는 것만으로도 JPA 동작을 훨씬 예측하기 쉬워집니다. 객체를 만들었다고 바로 DB와 연결되는 것이 아니고, persist() 로 영속성 컨텍스트에 올린 뒤에야 관리가 시작됩니다. 이후 필드 변경은 메모리 안에서 추적되다가 flush() 나 commit 시점에 SQL로 반영됩니다. 마지막으로 detach() 는 관리 대상에서 분리하고, remove() 는 삭제 예정 상태로 바꿉니다. 왜 EntityManager를 영속성 컨텍스트로 이해해야 할까 EntityManager 를 메서드 모음으로만 보면 persist() 는 저장, find() 는 조회, remove() 는 삭제처럼 따로따로 보입니다. 하지만 실제로는 모두 영속성 컨텍스트를 조작하는 행위입니다. 예를 들어 find() 는 단순 조회가 아닙니다. 먼저 1차...

스프링에서 JPA를 쓰는 이유: DAO 반복 코드를 줄이고 데이터 접근을 더 안정적으로 설계하는 법 빠른 답 JPA는 반복 CRUD와 DAO 구현을 줄여 도메인 로직에 더 집중하게 해준다. Spring Data JPA를 쓰면 메서드 이름 쿼리, 페이징, 정렬, 감사 기능을 같은 리포지토리 모델로 다룰 수 있다. 변경 감지와 트랜잭션 관리 덕분에 업데이트 로직이 단순해진다. 다만 생성된 SQL을 믿고 넘기면 안 되고, 로그와 실행 계획으로 성능을 확인해야 한다. 목차 흐름으로 보기 왜 JPA가 필요한가 JPA와 Spring Data JPA가 줄여주는 반복 엔티티와 영속성 컨텍스트는 어떻게 움직이나 Spring Boot에서 먼저 켜야 할 최소 설정 메서드 이름 쿼리와 @Query를 고르는 기준 예제 쿼리와 결과를 먼저 읽어야 한다 생성된 SQL과 실행 계획은 반드시 확인해야 한다 인덱스와 성능 포인트를 같이 봐야 하는 이유 JPA를 어디까지 맡기고 어디서 SQL을 더 직접 봐야 하나 JPA를 쓸 때 자주 틀리는 지점 흐름으로 보기 JPA를 쓰는 핵심은 단순히 코드를 덜 쓰는 것이 아닙니다. 엔티티로 테이블 구조를 표현하고, 리포지토리로 조회 의도를 선언하고, 영속성 컨텍스트와 트랜잭션으로 변경을 반영하는 흐름을 일관되게 가져가는 데 있습니다. 그래서 JPA를 제대로 쓰려면 “코드가 짧아졌다”보다 “어떤 SQL이 언제 실행되는가”를 더 먼저 봐야 합니다. 왜 JPA가 필요한가 JDBC나 DAO 중심으로 데이터 접근 계층을 직접 쌓으면 처음에는 명확해 보입니다. 하지만 기능이 조금만 늘어나도 SQL 문자열, 파라미터 바인딩, 결과 매핑, 예외 처리, 트랜잭션 경계가 여러 곳에 반복됩니다. 조회 조건이 늘어나면 DAO 메서드는 금방 비대해지고, 서비스 계층은 비즈니스 규칙보다 데이터 접근 세부사항을 더 많이 신경 쓰게 됩니다. 예를 들어 주문 목록 하나만 생각해도 금방 복잡해집니다. 상태별 조회, 기간 조건, 정렬, 페이지네이션, 총 개수 조회,...