😄 트랜잭션

• 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위
• 데이터베이스에 접근하는 방법은 쿼리, 즉 여러개의 쿼리들을 하나로 묶는 단위
• ACID특징(A:독립성, C:일관성, I:독립성, D:지속성)

1️⃣ 원자성(atomicity)

• 'all or noting'
• 트랜잭션과 관련된 일이 모두 수행되었거나 수행되지 않았거나를 보장하는 특징
• 트랜잭션을 커밋했는데, 문제가 발생하여 롤백하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것
• 트랜잭션 단위로 여러 로직들을 묶을 때 외부 API호출을 하면 X
  -> 만약 있다면 롤백이 일어났을 때 어떻게 해야할 것인지 해결방법을 신경쓰고 트랜잭션 전파를 신경 써서 관리해야 한다.

ex) opertaion 단위들로 이루어지는 과정
1. 홍철이 잔고를 조회한다.
2. 홍철이 500만원을 뺀다.
3. 규영에게 500만원을 넣는다.

• opertaion 중 데이터베이스 사용자는 이 세가지의 과정을 볼수도 참여할 수 X
  -> 이 과정이 모두 끝나야 서로의 잔고를 확인할 수 있다.
• 만약 이 과정을 '취소'하게 되면 operation은 아예 없었던거처럼 잔고는 그대로이다.
  -> 이것이 'all or noting'의 개념이라고 할 수 있다.

commmit & rollback

• commit 과 rollback을 통해 데이터의 무결성을 보장
• 데이터 변경 전에 변경 사항을 쉽게 확인할 수 있고 해당 작업을 그룹화 가능

commit

• 여러 쿼리가 성공적으로 처리되었다고 확정하는 명령어
• 트랜잭션 단위로 수행
• 변경된 내용이 모두 영구적으로 저장되는 것
• '커밋이 수행되었다' = '하나의 트랜잭션이 성공적으로 수행되었다'
• update, insert, delete 쿼리가 하나의 트랜잭션 단위로 수행되고 이후에 데이터베이스에 영구 저장
  

rollback

• 트랜잭션으로 처리한 하나의 묶음 과정을 일어나기 전으로 돌리는 일(취소)
• 에러나 여러 이슈 때문에 트랜잭션 전으로 돌려야 하는 상황에서 발생
  

트랜잭션 전파

• 트랜잭션은 커넥션 단위로 수행하여 커넥션단위를 넘겨서 수행해야 한다
  -> 매번 넘겨주지 않고, 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 트랜잭션 전파

ex) Spring 프레임워크에서는 @Transactional 애너테이션을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리

@Service
@Trancsactional(readOnly = true)
public class MemberService {
	private final MemberRepository memberRepository;
    
    public MemberService(MemberRepository memberRepository){
    	this.memberRepository = memberRepository;
        }
}

2️⃣ 일관성(Consistency)

• '허용된 방식'으로만 데이터를 변경해야 하는 것을 의미
• 데이터베이스에 기록된 모든 데이터는 여러 가지 조건, 규칙에 따라 유효함을 가진다

3️⃣ 격리성 (Isolation)

• 트랜잭션 수행 시 서로 끼어들지 못하는 것
• 복수의 병렬 트랜잭션은 서로 격리되어 마치 순차적으로 실행되는 것처럼 작동되어야 하고, 데이터베이스는 여러 사용자가 같은 데이터에 접근할 수 있어야 한다
• 격리성은 여러 개의 격리 수준으로 나뉘어 격리성을 보장

격리 수준은 위로 갈수록 동시성이 강하지만 격리성은 약해지고, 아래로 갈수록 동시성은 약해지고 격리성은 강해진다.

격리 수준에 따라 발생하는 현상

• 격리 수준에 따라 팬텀리드, 반복 가능하지 않은 조회, 더티리드가 있다

팬텀 리드

• 한 트랜잭션 내에서 동일한 쿼리를 보냈을 때 해당 조회 결과가 다른 경우

ex)
1.사용자 A가 회원 테이블에서 age 12 이상인 회원들을 조회하는 쿼리를 보낸다.
2. 세개의 테이블이 조회 -> 사용자 B가 age 15인 회원 레코드를 삽입
3. 그 다음은 세개가 아닌 네개의 테이블이 조회된다.

반복 가능하지 않은 조회

• 한 트랜잭션 내의 같은 행에 두 번 이상 조회가 발생하는데 그 값이 다른 경우

ex)
1. 사용자 A가 상품 100개 데이터를 가졌다
2. 그 이후 사용자 B가 그 값을 1로 변경 후 커밋
3. 사용자 A는 100이 아닌 1을 읽는다

팬텀리드, 반복 가능하지 않은 조회 차이

• 반복가능하지 않은 조회는 행 '값'이 달라질 수 있다
• 팬텀리드는 '다른 행'이 선택될 수 있다

더티 리드

• 반복 가능하지 않은 조회와 유사
• 한 트랜잭션이 실행 중일 때 다른 트랜잭션에 의해 수정되었지만, 아직 '커밋되지 않은'행의 데이터를 읽을 수 있을 때 발생

ex) 사용자 A의 100개 데이터가 1로 변경된 내용이 '커밋되지 않은' 상태여도 이후로 사용자 B가 조회한 결과가 1로 나오는 경우

격리 수준

SERIALIZABLE

• 트랜잭션을 순차적으로 진행시키는 것
• 여러 트랜잭션이 동시에 같은 행에 접근 X
• 이 수준은 매우 엄격한 수준으로 해당 행에 대해 격리시키고, 이후 트랜잭션이 이 행에 대해 일어나면 기다려야 한다.
  -> 그렇기 때문에 교착 상태가 일어날 확률이 많고 가장 성능이 떨어지는 격리 수준

REPEATABLE_READ

• 하나의 트랜잭션이 수정한 행을 다른 트랜잭션이 수정할 수 없도록 막아주지만 새로운 행을 추가하는 것은 막지 않는다
  -> 따라서 이후에 추가된 행이 발견될 수 있다

READ_COMMITTED

• 가장 많이 사용되는 격리 수준
• MYSQL8.0, PostgreSQL, SQL Server, 오라클에서 기본 값으로 설정
• READ_UNCOMMITTED와는 달리 다른 트랜잭션이 커밋하지 않은 정보는 읽을 수 없다
  -> 즉, 커밋 완료된 데이터에 대해서만 조회를 허용
• but, 어떤 트랜잭션이 접근한 행을 다른 트랜잭션이 수정 가능
  -> 트랜잭션 A가 수정한 행을 트랜잭션 B도 수정 가능하여, 트랜잭션 A가 같은 행을 다시 읽을 때 다른 내용을 발견할 수 있다

READ_UNCOMMITTED

• 가장 낮은 격리 수준
• 하나의 트랜잭션이 커밋되기 이 전에 다른 트랜잭션에 노출되는 문제 발생, but 가장 빠르다
• 데이터 무결성을 위해 되도록이면 사용하지 않는 것이 이상적
• 몇몇 행이 제대로 조회되지 않더라도 괜찮은 거대한 양이 데이터를 '어림잡아' 집계라는 데는 사용해도 좋다

4️⃣ 지속성(durability)

• 성공적으로 수행된 트랜잭션은 영원히 반영되어야 하는 것을 의미
• 데이터베이스에 시스템 장애가 발생해도 원래 상태로 복구하는 회복 기능이 있어야함을 뜻
  -> 데이터베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공

잠깐) 체크섬 & 저널링

체크섬

• 중복 검사의 한 형태로, 오류 정정을 통해 송신된 자료의 무결성을 보호하는 단순한 방법

저널링

• 파일 시스템 또는 데이터베이스 시스템에 변경 사항을 커밋하기전에 로깅하는 것
• 트랜잭션 등 변경 사항에 대한 로그를 남기는 것

😃무결성

• 데이터의 정확성, 일관성, 유효성을 유지하는 것
• 무결성이 유지되어야 데이터베이스에 저장된 데이터 값과 그 값에 해당하는 현실 세계의 실제 값이 일치하는지에 대한 산뢰가 생긴다.

개체 무결성

• 기본키로 선택된 필드는 빈 값을 허용하지 않는다

참조 무결성

• 서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 한다

고유 무결성

• 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성 값은 모두 고유한 값을 가진다

NULL 무결성

• 특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값은 NULL이 될 수 없다는 제약조건