DB 격리수준, 스프링의 트랜잭션

트랜잭션

일이 처리되기 위한 가장 작은 단위로 여러 개의 트랜잭션이 모여서 하나의 트랜잭션으로 묶일 수도 있다. 이걸 서비스라고 부른다.

 

DB 격리수준

오라클, MySQL의 격리수준 전략이 다르다.

 

1. 오라클

오라클에서는 DB 격리수준 전략으로 READ COMMIT을 사용한다. COMMIT된 것만 READ 한다는 뜻!

 

이 상황에서 B가 empno가 11번을 찾으면 kim을 찾게 된다. 왜냐하면 오라클은 READ COMMIT 전략이라서 커밋된 것만 READ하기 때문이다. update문으로 kim이 park으로 update되긴 했지만 commit이 되지 않았기 때문에 이 타이밍에 11번을 찾으면 kim을 찾게 된든 것이다. 만약 이 이후에 A가 commit을 해준 후 B가 select 11번을 하게 되면 park을 찾을 것이다.

 

DB에서 데이터 변경을 요청하는 어떤 쿼리문(INSERT, DELETE, ...)이 날라오면 이전 데이터를 들고 있는 undo 영역에서 실행되게 된다. 커밋을 하면 undo 영역의 데이터가 바뀌게 되는 원리

 

READ COMMIT의 정합성 문제

A가 커밋을 하기 전엔 아무리 update 후 select를 해도 undo 영역에서 값을 찾기 때문에 바뀐 데이터를 찾을 수가 없다.

 

보통 트랜잭션은 데이터가 바뀌는 경우에 커밋을 하면서 사용한다. B의 경우 select만 하기 때문에 트랜잭션을 시작시킬 필요가 없다. 근데 select를 하다보면 항상 동일한 값이 나와야 하는데 중간에 A의 commit으로 인해 다른값이 나오게 된다.

 

B가 만약 트랜잭션을 시작한 후 select를 하다가 마지막에 insert문으로 위의 select로 받은 값들을 연산해서 넣는다고 가정해보자. 이러면 중간에 다른 트랜잭션에 의해 값이 변경되면 예상값과 다른게 되는 문제가 생긴다. 이렇게 되면 데이터의 정합성이 깨지면서 부정확하게 된다.

 

이렇게 정합성이 깨져서 데이터가 보였다가 안보였다가 하는 현상을 PHANTOM READ라고 한다.

이 문제를 해결하려면 repeatable read 방식을 사용해야 한다.

 

2. MySQL

MySQL은 InnoDB 스토리지 엔진을 사용하는데 Repeatable read 이상의 방식을 사용해서 부정합이 발생하지 않는다.

트랜잭션이 시작되고 select를 해서 kim을 얻었다면 그 트랜잭션의 종료 시점까지 select를 아무리 해도 동일한 kim을 얻어내는 방식이다. 

 

또한 트랜잭션이 시작되고 종료되는 시점까지 select를 계속해서 kim을 얻다가 중간에 안보이는 현상 즉, PHANTOM READ가 발생하는 문제도 발생하지 않는다. 

 

T(12) 트랜잭션에 의해 undo가 바뀌었지만 로그를 보고 먼저 시작된 T(11)은 T(11) 이전의 undo 데이터에서 select를 수행한다. 즉, 자기 번호보다 낮은 로그를 보고 select하는 것이다. 

 

만약 T(11)이 트랜잭션이 아니라 그냥 select문만 계속 날리는 상황에서 중간에 다른 트랜잭션의 커밋으로 undo 데이터가 바뀌었을 경우엔 어떻게 될까? READ COMMIT처럼 커밋된 시점부터 select 값이 변경될 것이다. 그래서 스프링에서는 CRUD 작업 중 CUD 작업은 데이터의 변경이 이뤄지니까 당연히 @Transaction 어노테이션을 붙여주고, Read 즉, select는 굳이 트랜잭션을 붙여줄 필요가 없지만 데이터의 정합성을 위해서 @Transaction 어노테이션을 붙여준다.

 

 

 

스프링부트의 트랜잭션

 

스프링 실행 과정

1. 톰켓 시작 - 서버 작동!
2. 서버 작동을 위해 web.xml 읽기
3. context.xml 읽어서 DB에 연결되는 지 테스트

이렇게 스프링이 실행되면 다음과 같이 세팅된다. (송금 시스템)

 

홍길동이 장보고에게 10000원을 송금!

 

 

 

 

 

출처 : https://www.youtube.com/c/%EB%A9%94%ED%83%80%EC%BD%94%EB%94%A9