트랜잭션이란 ?

1. 트랜잭션이란 ?

트랜잭션을 한마디로 설명하자면 "모든 명령어의 성공 또는 실패를 한꺼번에 모아서 처리하는 것" 하고 할 수 있습니다.

만일, 여러 명령어를 한 번에 처리하다가 그 중 하나라도 실패하면, 트랜잭션 내의 모든 명령어가 무효화(롤백)됩니다.

 

💰 예를 들어, 은행에서 다른 계좌로 돈을 송금하는 상황을 가정해 보겠습니다. 

1. 내 계좌에서 돈을 출금하고

2. 다른 계좌로 돈을 입금하면 송금이 성공합니다 !

 

하지만, 만약 두번째 과정에서 오류가 발생해 입금이 되지 않으면, 돈이 어딘가로 사라지게 됩니다 🤔

이런 상황을 방지하기 위해서는, 1번과 2번 과정을 하나의 트랜잭션으로 묶어야 합니다 

이렇게 하면 둘 중 하나라도 실패하면 전체 트랜잭션이 롤백되어, 오류를 방지할 수 있습니다. !

---

2. 트랜잭션의 성질

트랜잭션은 ACID 라고 불리는 총 4가지의 성질을 가지고 있습니다. 

성질	설명	예시
A tomicity (원자성)	트랜잭션은 부분적으로 완료될 수 없으며, 전체가 완료되거나 아예 실행되지 않아야 한다.	출금만 성공하고 입금이 실패하면 안 된다.
C onsistency (일관성)	트랜잭션이 성공적으로 완료되면 항상 일관성 있는 데이터베이스 상태로 유지되어야 한다.	계좌 이체 전과 후의 돈의 합이 같아야 한다.
I solation (독립성,격리성)	트랜잭션 수행 중 다른 트랜잭션의 작업이 끼어들지 않도록 보장된다.	출금 후, 다른 트랜잭션이 내 계좌의 금액을 수정하지 못하도록 해야 한다.
D urablility (영속성,지속성)	성공적으로 수행된 트랜잭션은 시스템 장애가 발생하더라도 영구적으로 반영된다.	시스템에 문제가 생기더라도, 커밋된 데이터는 DB에 영구적으로 반영되어야 한다.

 

하지만 ACID 원칙을 완벽하게 지키면 동시성이 떨어지게 됩니다 ⬇️

그렇기 때문에 ACID 원칙을 희생하여 동시성을 얻을 수 있는 방법인 격리 수준 (isolation level) 을 조정할 수 있는 방법을 제공합니다

 

---

3. 트랜잭션 격리 수준 (isolation level)

격리 수준은 3가지 문제가 발생하는지에 따라서 분류합니다. 

1. Dirty Read

2. Non-Repeatable Read 

3. Phantom Read

 

 

3-1. Dirty Read (비커밋 읽기)

트랜잭션에서 커밋되기 전 작업 내용을 다른 트랜잭션에서 볼 수 잇는 현상을 Dirty Read 라고 합니다.

 

예를 들어서 

• 트랜잭션 A 에서 id: 22, name: 이름인 row 를 insert 하고 커밋하지 않은 상태에서, 
• 트랜잭션 B 가 id: 22 를 select 하면, B 는 A 의 데이터를 읽을 수 있습니다. 
• 이때 A 트랜잭션이 커밋되지 않고 롤백되면, 트랜잭션 B 는 잘못된 데이터를 읽은 셈이 되어 데이터 정합성에 문제가 생깁니다 💥

 

이게 가능한 이유는 바로 InnoDB 엔진이 트랜잭션을 커밋하는 방식 때문입니다. 

InnoDB 는 커밋되지 않은 작업이라도 실행한 쿼리를 DB 에 적용합니다. 

즉, log를 보고 특정 시점의 snapshot 을 복구하는 consistent read 를 하지 않고, 해당 시점의 DB 를 바로 읽으면 Dirty Read 가 발생합니다. 

consistent read 란 ?
SELECT 시 현재 DB 값이 아닌 특정 시점의 DB snapshot 을 읽어오는 방식을 의미합니다. 
해당 snapshot 은 커밋된 변화만을 포함하고 있으며, InnoDB 는 쿼리 실행 시 해당 시점의 DB snapshot 을 복구하기 위해 log 를 사용합니다.

 

 

3-2. Non-Repeatable Read (비반복 읽기)

한 트랜잭션에서 같은 쿼리를 두 번 실행했을 때 그 사이에 다른 트랜잭션이 값을 수정하거나 삭제하여 두 쿼리의 결과가 달라지는 현상을 의미합니다. 

 

예를 들어서

 

• 트랜잭션 A가 SELECT balance FROM account WHERE id = 1을 실행하여 계좌 잔액을 조회합니다.
• 그 사이에 트랜잭션 B가 해당 계좌의 잔액을 업데이트하거나 삭제합니다.
• 트랜잭션 A가 다시 같은 쿼리를 실행하면, 두 번째 결과는 첫 번째와 달라질 수 있습니다.

이로 인해 한 트랜잭션 내에서 일관성 없는 결과가 발생합니다.

 

 

3-3. Phantom Read (가상 읽기)

한 트랜잭션 안에서 일정 범위의 레코드를 두번 이상 읽을 때, 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상을 의미합니다.

 

예를 들어서

• 트랜잭션 A가 특정 범위의 데이터를 조회하는 SELECT 쿼리를 실행합니다. 예를 들어, balance > 1000 조건으로 조회한 결과가 A 트랜잭션 내에서 5개의 레코드를 반환한다고 가정합니다.
• 그 사이에 트랜잭션 B가 동일한 범위의 데이터를 삽입하거나 삭제합니다. 예를 들어, balance > 1000 조건에 맞는 새로운 레코드를 삽입합니다.
• 트랜잭션 A가 다시 같은 범위의 데이터를 조회하면, 첫 번째 쿼리에서 없던 레코드가 두 번째 쿼리에서 나타나는 현상이 발생합니다.

이로 인해, 트랜잭션 내에서 일관성 없는 데이터 결과를 보게 되어, 데이터 정합성에 문제가 생길 수 있습니다.

 

 

3-4. 트랜잭션 격리 수준

위의 3가지 문제가 발생하는지 여부에 따라서 트랜잭션 격리 수준이 결정되는데, 그건 아래 표와 같이 결정됩니다 

분리 레벨	Dirty Read	Non-Repeatable Read	Phantom Read
READ UNCOMMITEED	O	O	O
READ COMMITTED	-	O	O
REPEATABLE READ	-	-	O
SERIALIZABLE	-	-	-

• READ UNCOMMITTED
  • 문제 발생 : Dirty Read, Non-Repeatable Read, Phantom Read 발생
  • 커밋되지 않은 데이터를 읽을 수 있습니다. 
  • 오라클은 이 격리 수준을 지원하지 않습니다. 

• READ COMMITTED
  • 문제 발생 : Non-Repeatable Read, Phantom Read 발생
  • 커밋된 데이터만 읽을 수 있습니다.
  • DB2, SQL Server, Sybase 의 경우 S-Lock 하나의 레코드를 읽을 때 Lock 을 설정하고, 해당 레코드에서 빠지는 순간 Lock 을 해제하는 방식으로 S-Lock 을 이용해서 구현합니다.
• REPEATABLE READ
  • 문제 발생 : Phantom Read 발생
  • 같은 트랜잭션 내에서 반복되는 조회는 항상 같은 값을 조회합니다. 
  • 트랜잭션이 시작될 때의 시점을 기준으로 일관된 데이터를 제공합니다
  • InnoDB 의 기본 격리 수준입니다.
• SERIALIZABLE
  • 문제 발생 : 모든 문제가 발생하지 않습니다. 
  • 가장 높은 격리 수준으로, 트랜잭션이 완료될 때까지 데이터에 대한 업데이트나 삽입이 불가능합니다
  • 모든 SELECT 에서 해당 행에 S-Lock 이 걸리므로 동시성이 가장 떨어지고, Deadlock 이 발생할 수 있습니다.
  • 많이 사용하지 않습니다.

---

4. ☕️ 스프링에서 트랜잭션 사용하는 법

스프링에서는 @Transactional 어노테이션을 사용해 트랜잭션을 쉽게 처리할 수 있습니다. 

이 어노테이션은 메소드나 클래스에 적용할 수 있으며, 트랜잭션의 시작과 끝을 자동으로 관리합니다 !

import org.springframework.transaction.annotation.Transactional;

@Transactional
class Test {

}

 

위 코드처럼 @Transactional 어노테이션을 메소드나 클래스에 추가하면 해당 메소드 또는 클래스 내에서 수행되는 모든 데이터베이스 작업이 트랜잭션으로 묶입니다

 

또한, 격리수준도 설정할 수 있는데요.

@Transactional 어노테이션에서 isolation 속성을 사용하면 됩니다

예를 들어, 격리 수준을 SERIALIZABLE로 설정하려면 다음과 같이 할 수 있습니다.

import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.annotation.Isolation;

@Transactional(isolation = Isolation.SERIALIZABLE)
class Test {
}