Transaction

Transaction

• 단일한 논리적인 작업 단위 (a single logical unit of work)
• 논리적인 이유로 여러 SQL문들을 단일 작업으로 묶어서 나누어 질 수 없는 것
• transaction의 SQL문들 중에 일부만 성공해서 DB에 반영되는 일은 일어나지 않는다.

START TRANSACTION #실행과 동시에 autocommit은 off 된다
...
...
...
COMMIT #or ROLLBACK 
#COMMIT이란 지금까지 작업한 내용을 DB에 영구적으로(Permanently) 저장하는 것
#ROLLBACK이란 지금까지 작업들을 모두 취소하고 transaction이전 상태로 되돌린다
#transaction의 종료를 의미 autocommit이 원래 설정으로 돌아간다

일반적인 패턴

transaction에 진입한 후 데이터 읽기, 쓰기 등의 SQL문들을 포함한 로직을 수행한다. 이러한 과정중 문제없이 동작했다면 commit을 통해 DB에 데이터를 저장한다. 반대로 실행과정에서 문제가 발생한다면 rollback에 의해 DB의 데이터들을 transaction이전 상태로 되돌린다.

ACID

Atomicity (원자성)

• transaction은 논리적으로 더 이상 나누어 질 수 없는 작업단위이기 때문에 transaction내의 모든 SQL은 성공해야 한다.
• 중간에 SQL문이 실패하면 지금까지의 작업을 모두 취소하여 아무일도 없던 것처럼 rollback한다
• ALL or NOTHING

Consistency (일관성)

• transaction은 DB의 상태를 consistent상태에서 또 다른 consistent상태로 바꿔줘야 한다
• constraints, trigger 등을 통해 DB에 정의된 rules을 transaction이 위반했다면 rollback해야한다
• transaction이 DB에 정의된 rule을 위반했는지 DBMS가 commit전에 확인하고 알려준다

Isolation (고립성)

• 여러 transaction들이 동시에 실행되어도 하나의 transaction이 실행되는 것 처럼 만든다
• DBMS에는 여러 종류의 isolation level이 존재한다
• 개발자가 isolation level중 어떤 level로 transaction을 동작할지 결정 할 수 있다
• concurrency control의 주된 목표가 isolation이다.

Durabiliy (영존성)

• commit된 transaction은 DB에 영구적으로 저장한다
• DB System에 문제가 발생해도 commit된 transaction은 DB에 남아 있는다

Shcedule

• 여러 transaction들이 동시에 실행될 때 각 transaction에 속한 operations들의 실행순서
• 각 transaction 내의 operations들의 순서는 변하지 않는다.

Serial Schedule

• transaction들이 겹치지 않고 한 번에 하나씩 실행되는 schedule
• 한 번에 하나의 transaction만 실행되기 때문에 좋은 성능을 낼 수 없다.

Nonserial Schedule

• transaction들이 겹쳐서(interleaving) 실행되는 schedule
• transaction들이 겹쳐서 실행되기 때문에 동시성이 높아져서 같은 시간동안 더 많은 transaction들을 처리할 수 있다.
• transaction들이 어떤 형태로 겹쳐서 실행되는지에 따라 이상한 결과를 받을 수 있다.

Conflict

세 가지 조건을 모두 만족하면 conflict
1. 서로 다른 transaction 소속
2. 같은 데이터에 접근
3. 최소 하나는 write operation이다

Conflict equivalent

두 가지 조건을 모두 만족하면 Conflict equivalent
1. 두 schedule은 같은 transaction들을 가진다
2. 어떤(any) Conflicting operations의 순서도 양쪽 schedule 모두 동일하다

Confilct serializable

• serial schedule과 conflic equivalent 일때를 의미

Unrecoverable schedule

• schedule내에서 commit된 transaction이 rollback된 transaction이 write했었던 데이터를 읽은 경우
• rollback을 해도 이전 상태(transaction 실행 전)로 회복이 불가능할 수 있기 때문에 이런 schedule은 DBMS가 허용하면 안된다

recoverable schedule

- 내부 transaction이 먼저 commit이 되어야 한다.
- schedule 내에서 그 어떤 transaction도 자신이 읽은 데이터를 write한 transaction이 먼저 commit/rollback전 까지는 commit하지 않는 경우
- 하나의 transaction이 rollback하면 의존성이 있는 다른 transaction도 rollback해야 한다.
	○ 이것을 cascading rollback
	○ 여러 transaction의 rollback이 연쇄적으로 일어나면 처리하는 비용이 많이 든다
- 해결# 데이터를 write한 transaction이 commit/rollback 한 뒤에 데이터를 읽는 schedule만 허용하자
	

cascadeless schedule

- schedule 내에서 어떤(any) transaction도 commit되지 않은 transaction들이 write한 데이터는 읽지 않는 경우

strict schedule
- schedule 내에서 어떤 transaction도 commit되지 않은 transaction들이 write한 데이터는 쓰지도 읽지도 않는 경우
- rollback시 recovery가 쉽다