일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- Numpy
- 스프링 핵심원리
- 이것이자바다
- 김영한
- 불친절한SQL프로그래밍
- 항해플러스 회고
- 항해 추천인
- 자바의정석
- 스프링MVC
- Spring
- 자바공부
- 항해플러스 백엔드
- Secure Coding
- 인프런
- 스프링
- 스프링입문
- 자바연습문제
- 불친절한 SQL 프로그래밍
- 항해플러스 백엔드 7기
- 항해플러스
- 스프링 부트와 JPA
- JPA
- 서블릿
- 시큐어코딩
- Java의정석
- Python
- java
- 자바의정석 연습문제
- 항해 추천인코드
- 제네릭
- Today
- Total
Continuous Challenge
트랜잭션이란? 트랜잭션 격리수준으로 동시성과 정합성 사이의 균형 맞추기 본문
트랜잭션(Transaction)
데이터베이스에서 하나의 작업 단위로 실행되는 연산 묶음
트랜잭션의 4가지 특징 (ACID 원칙)
- A (Atomicity, 원자성) : 모든 작업이 하나의 단위로 수행되며, 일부만 실행되거나 중간에 실패하면 전체가 롤백됨.
- C (Consistency, 일관성) : 트랜잭션이 실행된 후 데이터가 일관된 상태를 유지해야 함.
- I (Isolation, 고립성) : 동시에 여러 트랜잭션이 실행될 때 각 트랜잭션이 독립적으로 실행되어야 함.
- D (Durability, 지속성) : 트랜잭션이 성공적으로 완료되면 그 결과가 영구적으로 반영되어야 함.
트랜잭션의 기본 연산, 커밋과 롤백
커밋(COMMIT)
트랜잭션 내에서 실행된 모든 작업을 영구적으로 저장하는 명령어.
커밋 이후에는 롤백 불가능
롤백(ROLLBACK)
트랜잭션 내에서 실행된 작업을 모두 취소하는 명령어
오류 발생 시 데이터 정합성을 유지하기 위해 사용됨.
세이브포인트(SAVEPOINT)
트랜잭션 내에서 특정 지점을 지정하여, 전체 롤백이 아니라 부분 롤백을 가능하게 하는 기능.
트랜잭션을 중간 단계로 나누어 필요할 때 일부만 되돌릴 수 있도록 도와줌.
세이브포인트 사용 상황
- 긴 트랜잭션에서 일부 작업만 취소해야 할 때
- 여러 단계로 이루어진 프로세스 중 일부만 문제가 발생했을 때
- 롤백을 실행하더라도 일부 작업은 유지하고 싶을 때
트랜잭션 격리 수준(Transaction Isolation Levels)
여러 트랜잭션이 동시에 실행될 때, 서로의 작업이 얼마나 영향을 미칠 수 있는지를 결정하는 데이터베이스 설정.
격리수준 | 설명 | Dirty Read | Non-Repeatable Read |
Phantom Read | 성능 |
READ UNCOMMITED | 읽기 허용 커밋되지 않은 데이터 허용 |
발생 | 발생 | 발생 | 빠름 |
READ COMMITED | 커밋된 데이터만 읽기 | 방지 | 발생 | 발생 | 중간 |
REPEATABLE READ | 반복 조회 시 같은 데이터 보장 | 방지 | 방지 | 발생 | 느림 |
SERIALIZABLE | 완전한 격리 동시 실행 거의 불가 |
방지 | 방지 | 방지 | 매우 느림 |
더티 리드(Dirty Read)
트랜잭션이 아직 커밋되지 않은 데이터를 다른 트랜잭션에서 읽을 수 있는 현상
한 트랜잭션이 데이터를 변경했지만 커밋하지 않았는데, 다른 트랜잭션이 그 데이터를 읽을 수 있는 경우.
🚨 더티 리드 발생 예제
상황: 은행 계좌 잔액 조회
1) 트랜잭션 A에서 사용자 계좌의 잔액을 1,000,000원 → 500,000원으로 변경 (하지만 아직 COMMIT 안 함)
2) 트랜잭션 B에서 사용자가 잔액을 조회 → 500,000원이 조회됨
3) 트랜잭션 A에서 ROLLBACK을 수행하여 원래 1,000,000원으로 복구됨
4) 트랜잭션 B가 잘못된 데이터(500,000원)를 보고 결제를 진행 → 오류 발생
반복 불가능한 읽기(Non-repeatable Read)
트랜잭션이 같은 데이터를 두 번 조회했을 때, 그 사이에 다른 트랜잭션이 값을 변경하여 두 번 조회한 결과가 달라지는 현상
데이터의 정합성이 깨질 수 있음
🚨 반복 불가능한 읽기 발생 예제
상황: 은행 계좌 잔액 조회
1) 트랜잭션 A에서 사용자 계좌의 잔액을 조회 → 1,000,000원
2) 트랜잭션 B에서 계좌 잔액을 500,000원으로 변경 후 COMMIT
3) 트랜잭션 A에서 같은 계좌의 잔액을 다시 조회 → 500,000원
4) 트랜잭션 A에서 같은 데이터를 두 번 조회했는데, 결과가 다름 → Non-Repeatable Read 발생
팬텀 리드(Phantom Read)
트랜잭션이 동일한 조건으로 두 번 데이터를 조회했을 때, 그 사이에 다른 트랜잭션이 새로운 데이터를 삽입하거나 삭제하여 결과가 달라지는 현상.
🚨 팬텀 리드 발생 예제
상황: 호텔 예약 시스템
1️⃣ 트랜잭션 A에서 "잔여 객실 개수를 조회" → 결과: 5개
2️⃣ 트랜잭션 B에서 새로운 객실을 추가 후 COMMIT
3️⃣ 트랜잭션 A에서 같은 조건으로 다시 조회 → 결과: 6개
4️⃣ 같은 트랜잭션 내에서 조회했는데, 결과가 다름 → Phantom Read 발생
'DB' 카테고리의 다른 글
[DB] RDBMS 에 대해 알아보자 (차수, 카디널리티, 키, 무결성) (0) | 2025.03.13 |
---|---|
[DB] 두둥...! DBMS 의 등장 (0) | 2025.03.13 |