-
하나의 흐름을 안전하게 처리하도록 보장
-
하나의 거래를 안전하게 처리하게 보장?
EX) 은행거래!
5000원 계좌 이체
A의 잔고를 5000원 감소 B의 잔고를 5000원 증가
2가지 작업이 합쳐서 하나의 작업처럼 안전하게 동작해야하는 것 처럼..- 하나의 거래를 안전하게 처리해 준다는 뜻으로 시작하자
정상반영 : 커밋 실패: 롤백!
트랜잭션 ACID
- 하나의 거래를 안전하게 처리해 준다는 뜻으로 시작하자
-
원자성, 일관성, 격리성, 지속성.. 항상 나오는 문장 ! 외우기가 어렵
격리수준
- READ UNCOMMITED (커밋되지 않은 읽기)
- READ COMMITTED (커밋된 읽기)
- REPEATABLE READ(반복 가능 읽기)
- SERIALIZABLE(직렬화 가능)
-
이 부분도 매일 까먹는다.
-
일반적으론 커밋된 읽기 많이 쓰는듯?
각 격리 수준의 자세한 설명
- READ UNCOMMITTED (커밋되지 않은 읽기)
- 가장 낮은 격리 수준.
다른 트랜잭션에서 아직 커밋되지 않은 변경 사항을 읽을 수 있음.
이로 인해 "더티 리드(Dirty Reads)" 문제가 발생할 수 있음, 즉 아직 확정되지 않은 데이터를 읽을 수 있습니다.
- READ COMMITTED (커밋된 읽기)
- 대부분의 데이터베이스 시스템의 기본 격리 수준.
커밋된 데이터만 읽을 수 있으며, 다른 트랜잭션의 커밋되지 않은 변경 사항은 보이지 않음.
"논리적 일관성(Consistent Read)"을 제공하지만, "팬텀 리드(Phantom Reads)"는 여전히 발생할 수 있음.
- REPEATABLE READ (반복 가능 읽기)
- 트랜잭션이 시작된 후에 읽은 데이터는 트랜잭션 내에서 여러 번 읽더라도 동일하게 유지됨.
이미 읽은 데이터에 대한 수정이나 삭제를 다른 트랜잭션이 수행할 수 없음.
그러나, 새로운 "팬텀 데이터"가 조회 범위에 추가되는 것을 막지 못함.
- SERIALIZABLE (직렬화 가능)
- 가장 높은 격리 수준.
트랜잭션들이 마치 순차적으로 실행되는 것처럼 격리됨.
모든 종류의 읽기 문제(더티 리드, 논리적 일관성 문제, 팬텀 리드)를 방지함.
동시성이 크게 감소할 수 있으며, 성능에 영향을 줄 수 있음.
항상 정리를 하지만 공부할 때만 외우고 또 잊어버린다. 반복적으로 봐야지
팬텀리드
-
한 트랜잭션이 동일한 쿼리를 두 번 실행했을 때, 첫 번째 쿼리와 두 번째 쿼리의 결과가 다른 경우 발생
-
결국 내가 이해한건 2~3번 격리수준 에서.
-
데이터를 조회할때 커밋된 사항만 봐야되는대 (일관적, 멱등성?)
-
만약 다른 트랜잭션에서 새로운데이터가 삽입 수정 삭제 된다면
-
일관성이 깨진다는 것 . 더 자세히 설명하면
READ COMMITTED
- 커밋된 데이터만 보니까 ! 이는 다시말해 새로 커밋된 (수정,삭제,삽입)
- 일어나면 다음 조회 시점에서 반영 -> 같은 쿼리 여러번 실행하면 일관성이 깨짐 !
Repeatable READ
-
트랜잭션이 시작할때 데이터에 대한 일관성을 보장
-
즉 한 트랜잭션 내에서 동일한 쿼리 반복해도 트랜잭선 시작이후 (수정 ,삭제 방지)
-
허나 다른 트랜잭션에서 삽입이 일어날시 팬텀리드 현상 발생
-
이 격리수준의 목적은 일관되지않는 읽기를 방지하는 것 이다.!
-
반복 불가능한 읽기? 일관되지 않는 읽기? 영어 어렵네
-
Non-repeatable reads? 이렇게 이해하면 되나?
일관된 뷰 (수정 , 삭제 방지)
-
일관적인 데이터를 계속 보장한다고 한다.
-
수정, 삭제에 영향을 받지 않음.
-
처음에 잘못 이해해서 삽질을 했내 처음 이해한건 영향을받지 않는다 로 해서
-
많이 헷갈렸다.
-
결론적으론 조회한 행데이터는 다른 트랜잭션에서 수정 삭제 시도 할 때
-
이를 방지하는 블록을 사용해 데이터 일관성 유지. (읽기 잠금)
-
이는 트랜잭션이 완료될 때 까지 유지
-
왜? 일관성과 격리를 보장해야 되기 때문 맨위에 ACID
삽입은 왜 못막지?
- 수정이나 삭제에 의한 변경사항은 트랜잭션에 반영하지 않는 것은
- 기술적으로 가능 하지만 ,
- 삽입은 막는건 복잡하다고 함.. 딥 다이브를 해야되나..
- 데이터에 대한 무결성을 유지함으로 애플리케이션이 이를 예측 하고
- 신뢰 할 수 있는 기반으로 작동하게
- 당연하지 ! 읽어온 데이터가 중간에 변경? 그리고 비즈니스 로직 실행?
- 예상치 못한 사이드 이펙트가 일어나지
동시성
- 데이터베이스 시스템에서 여러 트랜잭션이 동시에 실행 되는 능력
- 격리가 강할수록 동시성이 떨어진다.. 으음
일관성
- 격리수준이 높을 수록 일관성이 좋아짐
- 왜? 그만큼 락을걸어서 다른 트랜잭션이 내가 지금 사용하는 데이터를 막아버리니
- 데이터 수정이 안되니깐
- 격리는 여기까지
추가
-
일반적으로 SELECT 는 락을 사용하지 않음
-
데이터를 조회하는데 락을 걸고 싶을때가 있다. (select for update) 사용
-
왜 이런걸 사용할 때가? 다른 곳에서 변경하지 못하도록 강제로 막아야 될때
-
돈 관련 로직? 중요한거? 적절한 예시가없네
자동커밋 수동 커밋
- 결론 부터 말하면 트랜잭션은 수동 커밋
- 트랜잭션이 다 정상적으로 완료된 후 커밋!
- 이런식으로 예시로 할수 있다
- 다른 세션에서 셀렉트하면? 못봄!
- 대략적인 트랜잭션 임시코드
- 여기 참고해서 계속 설명
트랜잭션 프록시란?
-
트랜잭션 프록시는 원본 객체(대상 객체)를 대신하여 트랜잭션 관리 코드를 실행하는 임시 객체.
-
스프링이 @Transactional 애노테이션이 붙은 클래스나 메서드를 처리할 때, 원본 객체 대신 프록시 객체를 생성하고 이 프록시를 스프링 컨테이너에 빈(bean)으로 등록
-
이 프록시 객체는 내부적으로 원본 객체를 참조하고 있으며, 원본 객체의 메서드 호출 시 트랜잭션 관련 로직(예: 트랜잭션 시작, 커밋, 롤백)을 수행한 후 실제 메서드를 호출합니다.
왜 프록시를 사용하는가?
-
관심사의 분리: 비즈니스 로직과 트랜잭션 관리 로직을 분리함으로써 코드의 가독성과 유지보수성을 향상시킵니다. 개발자는 비즈니스 로직에 집중할 수 있으며, 트랜잭션 관리는 프레임워크가 담당합니다
-
선언적 트랜잭션 관리: @Transactional 애노테이션을 사용하여 선언적으로 트랜잭션을 관리할 수 있습니다. 이는 AOP(Aspect-Oriented Programming)를 기반으로 하며, 코드를 수정하지 않고도 트랜잭션 관리 정책을 적용_텍스트
프록시 내부 호출 문제
-
프록시 방식의 AOP를 사용할 때는 프록시를 통하지 않고 대상 객체의 내부에서 다른 메서드를 직접 호출하면 AOP가 적용되지 않는 문제가 발생할 수 있습니다.
-
이는 트랜잭션 관리뿐만 아니라 보안, 로깅 등 다른 AOP 기능에도 해당되는 일반적인 문제입니다. 이를 해결하기 위해선 메서드 간의 호출이 프록시를 거쳐 이루어지도록 설계 변경이 필요할 수 있습니다(예: self-injection, 별도의 빈으로 분리).
-
결론적으로 프록시가 선언된 메서드에서 내부 메서드 호출에 대해 주의
public 메서드만 트랜잭션 적용
-
스프링의 트랜잭션 AOP 기능은 public 메서드에만 트랜잭션을 적용하도록 기본 설정이 되어있다. 그래서 protected , private , package-visible 에는 트랜잭션이 적용되지 않는다
-
생각해보면 protected , package-visible 도 외부에서 호출이 가능하다. 따라서 이 부분은 앞서 설명한 프록시의 내부 호출과는 무관하고, 스프링이 막아둔 것이다.
-
그냥 스프링이 Public외 다 막아 놓음
테크코스
-
트랜잭션? 더이상 나눌수 없는 하나의 단위
-
모든 디비는 트랜잭션 지원
-
하나의 명령을 실행했을때 디비가 그 명령을 실행 해줄 것 의미
-
디비에서는 명령이 끝날때까지 수행 내역을 로그의 저장
-
데이터 베이스에 반영된 내용을 재반영하기 위한 Redo로그
-
수행을 실패해 이전의 상태로 되돌리는 undo log를 이용해 트랜잭션지원
-
이건뭐야..
