DB의 Concurrency Control에 대한 개념 정리

1. DB:ConcurrencyControl개념정리
1

2. Outline
Lock‑BasedProtocols
Timestamp‑BasedProtocols
DeadlockHandling
2

3. 주요내용
AtomicityConsistencyIsolationDurability(ACID):Transaction이지
켜야할4가지성질
A,C,D:recoverymanage에서설명(log)
I:concurrencecontrolmanager(locking)
Lock허용여부:data의consistence가유지되면허용
Lock‑based/Timestamp‑BasedProtocol설명/Lock‑based는대체
적으로Deadlock을발생시킴.
3

4. Lock‑BasedProtocols(1/3)
lock메카니즘은데이터엑세스에대한동시성제어
2가지모드
Exclusivemode
readx,writex
Sharedmode
reado,writex
lock요청은concurrencycontrol매니저에게요청하는것
(트랜젝션은granted된이후진행됨)
4

5. Lock‑BasedProtocols(2/3)
Lockcompatibilitymatrix
위matrix에true일때만lock을얻을수있음
1개이상의트랜젝션이sharedlock을쥐고있을수있음
Exclusivelock은하나의트랜젝션을초과해서얻을수없음
lock을못얻으면트랜젝션은대기
5

6. Lock‑BasedProtocols(3/3)
아래의lock은A와B사이에무언가가침투하면serializability가보장되지
않음
아래예제는잘못된locking
Lock을너무빨리풀면dataconsistence가깨짐.
lock프로토콜은모든트랜젝션이따라하야하는rule임
6

7. PitfallsofLock‑BasedProtocol(1/2)
T3와T4모두진행이안됨
lock‑S(B)와lock‑X(A)가각트랜젝션을wait로만들기때문
이상황을데드락이라함
T4의lock‑S(B)는이미Bdata에X‑lock이걸려있기때문에wait
T3의lock‑X(A)는이미Adata에S‑lock이걸려있기때문에wait
7

8. PitfallsofLock‑BasedProtocol(2/2)
데드락가능성은대부분은lock프로토콜에존재함
starvation은concurrencycontrol매니저가잘못설계되어있으면가능
함
트랜젝션이X‑lock을기다리는동안다른트랜젝션에S‑lock을기
다릴경우
데드락상황에서같은트랜젝션은반복적으로롤백됨
concurrencycontrol매니저를잘설계하면starvation방지가능
8

9. Two‑PhaseLockingProtocol(1/2)
conflict‑serializable스케쥴을보장
Phase1:GrowingPhase
트랜젝션이lock획득가능
트랜젝션이lockrelease불가능
Phase2:ShrinkingPhase
트랜젝션이lock획득불가능
트랜젝션에lockrelease가능
트랜젝션이각lock포인트에따라직렬화가능한것이보장됨
9

10. Two‑PhaseLockingProtocol(2/2)
two‑phaselocking은데드락방지를보장하진않음
Cascadingrollback은가능함
Strict2PL:Transaction이종료되는시점에모든x‑lock들을전부
unlock하는방법(x‑lock은종료될때까지계속유지)
Rigorous2PL:x‑lock뿐만아니라s‑lock을포함한모든lock을
Transaction이종료될때까지유지
10

11. ExampleofCascadingRollback#1
11

12. ExampleofCascadingRollback#2
T5에Failure가발생:T5가했던변경사항을전부Rollback해야함.‑>
Write(A)를원복해야함.
그러면T6의read(A)값도잘못된값을읽었기때문에Rollback됨.
T7의read(A)값도잘못된값을읽었기때문에Rollback발생‑>
CascadingRollback‑>치명적
12

13. Timestamp‑BasedProtocols(1/3)
각트랜젝션이시작될때timestamp를발행
oldtransaction에우선권부여
트랜젝션매니저는아래를관리
W‑timestamp(Q)isthelargesttimestampofanytransaction
thatexecutedwrite(Q)successfully
R‑timestamp(Q)isthelargesttimestampofanytransaction
thatexecutedread(Q)successfully
13

14. Timestamp‑BasedProtocols(2/3)
read나write연산의conflict시ts를따짐
만약Ti가read(Q)를발행한다고가정
TS(Ti)<W‑timestamp(Q)이면이미dirty된데이터를읽는다는
것이니Ti를롤백
TS(Ti)>=W‑timestamp(Q)이면read연산이수행되고R‑
timestamp(Q)가max(R‑timestamp(Q),TS(Ti))로업데이트
14

15. Timestamp‑BasedProtocols(3/3)
Ti가write(Q)를발행했다고가정
TS(Ti)<R‑timestamp(Q)이면이미읽은시간보다과거시간에
write를시도하는것이므로reject
TS(Ti)<W‑timestamp(Q)이면이미써진시간보다과거에write
를시도한것이므로역시reject
위케이스가아니면write연산은수행되고W‑timestamp(Q)는
TS(Ti)로업데이트
15

16. CorrectnessofTimestamp‑OrderingProtocol
timestamp‑ordering프로토콜은serializability를보장하여
precedencegraph의cycle이없음
타임스탬프프로토콜은트랜젝션의대기가없으므로데드락이없음
하지만cascade‑free는아니며recoverable하지않음
16

17. RecoverabilityandCascadeFreedom
타임스탬프프로토콜의문제점
Ti가abort,Tj가Ti에의해쓰여진데이터를이미읽었다가정
Tj는반드시abort되어야하지만이미commit되었다면복구불가능
나아가,Tj의값을읽은경우모두롤백되어야함
이런형태의롤백을cascadingrollback이라부름
솔루션
트랜젝션의구조화되어write가제일마지막에처리되어야함
모든쓰기트랜젝션은atomic해야함
17

18. DeadlockHandling
모든트랜젝션이다른트랜젝션을기다리고있으면시스템이데드락됨
데드락방지프로토콜이이를막아줌
각트랜젝션이시작되기전사용되는모든데이터를lock함(pre‑
declaration)
(graph‑basedprotocol)
18

19. DeadlockHandling#2
Prevention:아예Deadlock을발생시키지않기위해까다로운제약조건
을건다.
Detection:일정주기로deadlock이발생할지체크.
Resolution:Cycle이구성된Transaction중하나를강제종료해서
Deadlock복구‑‑>Cycle해제(victim)
“wait‑forgraph”:Dead‑lock발생여부를Check하는그래프.Cycle이
있으면Deadlock이다.
19

20. Timeout‑BasedSchemes
롤백트랜젝션이원본타임스탬프기준으로재시작됨
오래된트랜젝션이우선함
Timeout‑Base스키마
트랜젝션은특정시간동안만기다리고이후트랜젝션이롤백됨
데드락이불가능해짐
구현이간단하지만starvation문제가능성있음
좋은timeout값을정하기어려움
20

21. DeadlockDetection(1/2)
데드락은wait‑for그래프로탐지됨
그래프에서cycle이발생하면데드락상태임
21

22. DeadlockDetection(2/2)
22

23. DeadlockRecovery
데드락이탐지되면
몇몇트랜젝션은롤백되어야함
최소한의롤백비용을가지는희생자를찾아야함
롤백
전체롤백
더효과적인롤백은데드락을끊을수있는트랜젝션만롤백
같은트랜젝션이계속victim으로지정되면starvation가능성있음
롤백횟수를가중치로만들어starvation을피해야함
23