![[스프링부트 #9] 쿼리에서 중요한 트랜잭션 고립성(Isolation) 이해하기](https://image.inblog.dev?url=https%3A%2F%2Finblog.ai%2Fapi%2Fog-custom%3Ftitle%3D%255B%25EC%258A%25A4%25ED%2594%2584%25EB%25A7%2581%25EB%25B6%2580%25ED%258A%25B8%2B%25239%255D%2B%25EC%25BF%25BC%25EB%25A6%25AC%25EC%2597%2590%25EC%2584%259C%2B%25EC%25A4%2591%25EC%259A%2594%25ED%2595%259C%2B%25ED%258A%25B8%25EB%259E%259C%25EC%259E%25AD%25EC%2585%2598%2B%25EA%25B3%25A0%25EB%25A6%25BD%25EC%2584%25B1%2528Isolation%2529%2B%25EC%259D%25B4%25ED%2595%25B4%25ED%2595%2598%25EA%25B8%25B0%26tag%3DTemplate%2B1%26description%3D%26template%3D3%26backgroundImage%3Dhttps%253A%252F%252Fsource.inblog.dev%252Fog_image%252Fdefault.png%26bgStartColor%3D%252323ec86%26bgEndColor%3D%252323ec86%26textColor%3D%2523000000%26tagColor%3D%2523000000%26descriptionColor%3D%2523000000%26logoUrl%3D%26blogTitle%3DGyeongwon%2527s%2Bblog&w=2048&q=75)
1. 고립성 이란 ?
“동시성 환경에서 트랜잭션끼리 서로 간섭하지 않도록 격리하는 성질”을 말한다.
이 고립성이 중요한 이유는 다른 트랜잭션에서 보고 있는 데이터를, 내가 동시에 삭제하거나 변경하면 데이터 일관성이 깨질 수 있기 떄문이다.
2. 실전 사례: 삭제(DELETE)에서의 고립
시나리오 예시:
어떤 사용자가 게시글을 읽고 있는 중에,다른 사용자가 해당 게시글을 삭제하려 한다.
이럴 때 "고립을 언제 시킬지" 가 중요한 비즈니스 결정 포인트가 된다.
조회 후 고립 → 삭제 (보수적 전략)
select
후 데이터가 존재하고 아직 아무도 해당 데이터를 수정/삭제 중이 아닐 때만 삭제 수행
바로 고립 후 삭제 (공격적 전략)
조회 없이 바로 DELETE에 고립을 걸고 삭제
핵심은 비즈니스 규칙에 따른 판단
핵심은 비즈니스 규칙에 따른 판단한다.
- 고립을 걸지 않으면 빠르지만 데이터 충돌 위험
- 고립을 너무 많이 걸면 성능 저하 및 병목 발생
- 따라서 개발자가 비즈니스의 중요도, 충돌 가능성, 실시간성 등을 고려해 전략을 선택해야 함
3. 고립의 범위 : Row vs Table
고립 범위 | 설명 | 예시 |
Row-level | 특정 행만 고립시킴 | SELECT ... FOR UPDATE |
Table-level | 전체 테이블을 잠금 | LOCK TABLE board WRITE |
일반적으로는 Row-level 고립을 선호하지만, 대규모 수정이나 삭제에서는 Table-level이 필요할 수도 있다.
이 모든 결정은 결국, “우리 서비스에서 이 데이터가 얼마나 민감한가?”, “동시 작업 충돌이 얼마나 발생할 수 있는가?” 에 따라 달라진다.
Share article