오늘은 Service Layer 에서 자주 사용해본
@Transactional 에 대해서 알아보았습니다.
@Transactional 이란?
@Transactional 어노테이션은 트랜잭션에 대한 전파, 격리, 시간 초과, 읽기 전용 및 롤백 조건을 설정할 수 있고, 트랜잭션 관리자를 지정할 수도 있습니다.
트랜잭션의 성질
원자성(Atomicity) - 한 트랜잭션 내에서 실행한 작업들은 모두 성공하거나 모두 실패하는 걸로 간주합니다.
일관성(Consistency) - 트랜잭션은 일관성 있는 데이타베이스 상태를 유지합니다.
격리성(Isolation) - 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않도록 격리해주어야합니다.
지속성(Durability) - 트랜잭션을 성공적으로 마치면 결과가 항상 저장되어야 합니다.
다수의 트랜잭션이 경쟁시 발생할 수 있는 문제
다수의 트랜잭션이 동시에 실행되는 상황에선 트랜잭션 처리방식을 좀 더 고려해야 합니다. 예를들어 특정 트랜잭션이 처리중이고 아직 커밋되지 않았는데 다른 트랜잭션이 그 레코드에 접근한 경우 다음과 같은 문제가 발생할 수 있습니다.
Problem1 - Dirty Read
트랜잭션 A가 어떤 값을 1에서 2로 변경하고 아직 커밋하지 않은 상황에서 트랜잭션B가 같은 값을 읽는 경우, 트랜잭션 B는 2가 조회 됩니다.
트랜잭션 B가 2를 조회 한 후 혹시 A가 롤백되면 결국 트랜잭션B는 잘못된 값을 읽게 된 것입니다. 즉, 아직 트랜잭션이 완료되지 않은 상황에서 데이터에 접근을 허용할 경우 발생할 수 있는 데이터 불일치의 문제입니다.
Problem2 - Non-Repeatable Read
트랜잭션 A가 어떤 값 1을 읽었을때 이후 A는 같은 쿼리를 또 실행할 예정인데, 그 사이에 트랜잭션 B가 값 1을 2로 바꾸고 커밋해버리면 A가 같은 쿼리 두번을 날리는 사이 두 쿼리의 결과가 다르게 되어 버립니다.
즉, 한 트랜잭션에서 같은 쿼리를 두번 실행했을 때 발생할 수 있는 데이터 불일치의 문제입니다. Dirty Read에 비해서는 발생 확률이 적습니다.
Problem3 - Phantom Read
트랜잭션 A가 어떤 조건을 사용하여 특정 범위의 값들[0,1,2,3,4]을 읽었을때, 이후 A는 같은 쿼리를 실행할 예정인데, 그 사이에 트랜잭션 B가 같은 테이블에 값[5,6,7]을 추가해버리면 A가 같은 쿼리 두번을 날리는 사이 두 쿼리의 결과가 다르게 되어 버립니다.
즉, 한 트랜잭션에서 일정 범위의 레코드를 두번 이상 읽을 때 발생하는 데이터 불일치의 문제입니다.
참고 :
https://blog.naver.com/seek316/222707671228
https://goddaehee.tistory.com/167
