직렬성

# 서로 충돌하는 연산들(conflicting instructions)
1. li = read(Q), lj = read(Q)        =>   충돌하지 않음   
2. li = read(Q),  lj = write(Q)      =>  충돌함   
3. li = write(Q), lj = read(Q)       =>  충돌함
4. li = write(Q), lj = write(Q)       =>  충돌함
=> 최소 하나 write(고칠 때) 충돌. 둘 다 읽으면 문제없음

 

 

# 충돌 동등(conflict equivalent)

- 접근하는 데이터 다르면 충돌 없음 (예. Ti.read(x) Tj.write(y) )

- S가 충돌이 일어나지 않는 명령어들의 순서를 바꿔 SS로 변경되면 S와 SS는 충돌 동등함

 

 

# 우선순위 그래프(precedence graph) : 충돌 직렬성 테스팅

- cycle 발생 안 하면 직렬성 있음

- Ti가 read, write 함에 따라 Tj가 write 했을 때 충돌 발생 => 화살표 그림

 

 

# 직렬성(serializability)

- read, write만 고려

 

1. 충돌 직렬성(conflict serializability)

- S가 한 순차 스케줄에 충돌 동등하면 그 스케줄 S가 충돌 직렬적임

 

 

2. 뷰 직렬성(view serializability)
- 모든 충돌 직렬적인 스케줄은 뷰 직렬적임
- (일부 뷰 직렬적인 것은 충돌 직렬적이지 않을 수 있음)
- 충돌 동등보다 덜 엄격

1) 두 개의 스케줄이 본 내용이 같아야 함 : 
- 같은 값 읽어감(다른 값 x)
2) 어떤 스케줄이든 같은 값을 읽혀야 함
- 스케줄 끝나고 뒤에 나오는 트랜잭션이 같은 내용을 읽어감
3) 스케줄이 순차적 스케줄과 뷰 동등하면 뷰 직렬성 만족(일관성 보장)

 

=> 양쪽 T27의 read(Q)가 초기 값 읽음, 양쪽 T29의 write(Q)가 마지막에 수행
=> 뷰 직렬적인 스케줄
- blind write : read하지 않고 write(T28,29). 충돌 직렬적 x. 뷰 직렬성 o

 

 

# 뷰 동등(view equivalent)
각 데이터 항목 Q에 대해
1. S에 있는 Ti가 Q의 초기 값을 읽으면, Ti는 반드시 SS에서도 Q의 초기 값 읽어야 함
2. Ti가 S에서 read(Q)를 실행한 값이 Tj에서 write(Q)에서 만들어진 값이면, Ti의 read(Q) 연산은 SS에서도 Tj의 write(Q) 연산에서 만들어진 값 읽음
3. S에서 마지막 write(Q)를 수행하는 트랜잭션은 반드시 SS에서도 마지막 write(Q) 수행함

=> 1, 2는 각 트랜잭션이 두 스케줄에서 같은 값을 읽고 같은 계산을 수행한다는 것 보장
=> 3은 두 스케줄이 같은 최종 시스템 상태를 가진다는 것 보장

 

 

# 복구 가능한 스케줄(recoverable schedules)

- Ti의 commit이 Tj의 commit보다 앞서 있어야 함
- Ti가 abort 하면 Tj보다 abort 가능 => 연쇄적 롤백 발생(일관성 보존 위함)
- 일관성 보존

 

 

# 연쇄적 롤백(cascading rollback)

- 하나의 트랜잭션이 취소됨에 따라 다른 트랜잭션들이 따라서 취소
- 일관성 보존 위함
- commit 하지 않은 값 읽어서 발생
- 없던 걸로 함(undo) => 부담 심함

 

 

# 트랜잭션 고립성 수준(level)
=> 1 -> 4 일관성, 정확성 떨어지고, 성능 좋아짐
- commit, abort 하기 전에 write하지 않음(더티 기록 허용 안 함)
1. 직렬적(serializable) : default
- 일관성 강력하게 유지

2. 반복 읽기(repeatable read)
- 하나의 트랜잭션이 commit 된 값(같은 값)을 계속 읽음
- 일관성 깨질 수 있음
- 누가 데이터 insert 하면 값 변함 => 일관성 깨짐
- 비연쇄적 스케줄

3. 읽기 완료(read committed)
- 또 다른 누가 commit 하면 일관성 깨짐
- 완료된 데이터만 읽음 => 비연쇄적 스케줄

4. 읽기 미완료(read uncommitted)
- commit 되지 않은 데이터도 읽음 => 연쇄적 롤백 발생

 

 

# JDBC
- Connection.setAutoCommit(false)와 같은 API 함수를 사용해 자동 카밋 기능 해제
- Connection.setTransactionsolation(int level)로 고립성 수준 조정
- DBMS가 SQL이 날아오면 새로운 트랜잭션 시작인 줄 암 

 

# 팬텀 현상(phantom phenomenon)
- 충돌이 유령 데이터에 대해 발생