Transaction

여러 data item을 읽고 쓰는 프로그램의 한 실행 단위

DB Consistency

[전제] transaction의 중간 실행 결과는 inconsistent하다.

DB Consistency를 유지하기 위해선 Transaction의 ACID 속성을 만족시켜야 한다.

• failure 발생 시 atomicity, durability가 위배된다. 따라서 recovery syetem을 구축하고 rollback, recovery하여 transaction 속성을 다시 만족시킨다.
• concurrent transactions은 isolation을 해친다. 따라서 concurrency control을 통해 serializable schedule을 구성하고 이에 따라 transaction의 연산들을 차례로 실행시켜 isolation을 만족시킨다.

Isolation

실행 중인 transaction은 동시에 실행 중인 다른 transaction의 중간 및 완료된 수행 결과에 영향 받지 않는다.

실행 중인 transaction의 중간 수행 결과는 동시에 실행 중인 다른 transaction에 노출되지 않는다.

Transaction Isolation Levels

Nonserializable executions

• Unrecoverable Schedule:

• Dirty write: commit되지 않은 transaction이 write한 data item을 다른 transaction에서 write

• Dirty read: commit되지 않은 transaction이 write한 data item을 다른 transaction에서 read

• Non-repeatable read: commit된 transaction이 write(UPDATE)한 data item을 다른 transaction에서 read

• Phantom problem: commit된 transaction의 write(INSERT, DELETE) 연산에 의해 다른 transaction에서 data item이 새롭게 나타나거나 사라짐

What is the difference between Non-Repeatable Read and Phantom Read?

단일 transaction은 consistency property를 만족한다고 가정하자. 즉, transaction이 하나만 실행되면 DB consistency가 훼손되지 않는다. 이때 DBMS의 concurrency mechanism이 serializable schedule을 구성하여 동시 작업을 처리한다면 복합적인 transaction 실행 또한 DB consistency를 보장한다.

하지만 serializable schedule은 concurrency level이 낮으므로 DBMS는 isolation level을 조정하여 이를 개선하는 대신, DB consistency를 보장하지 않는 transaction 간의 nonserializable executions을 간과한다.