Lectures 7 & 8: Transactions -...
Transcript of Lectures 7 & 8: Transactions -...
Goalsforthispairoflectures
• Transactions areaprogrammingabstractionthatenablestheDBMStohandlerecovery andconcurrency forusers.
• Application:Transactionsarecriticalforusers• Evencasualusersofdataprocessingsystems!
• Fundamentals:Thebasicsofhow TXNswork• Transactionprocessingispartofthedebatearoundnewdataprocessingsystems
• GiveyouenoughinformationtounderstandhowTXNswork,andthemainconcernswithusingthem
Lectures7&8
Whatyouwilllearnaboutinthissection
1. Our“model”oftheDBMS/computer
2. Transactionsbasics
3. Motivation:Recovery&Durability
4. Motivation:Concurrency[nextlecture]
6
Lecture7>Section1
High-level:Diskvs.MainMemory
• Disk:
• Slow• Sequentialaccess
• (althoughfastsequentialreads)
• Durable• Wewillassumethatonceondisk,dataissafe!
• Cheap
7
Lecture7>Section3>Ourmodel
Platters
SpindleDisk head
Arm movement
Arm assembly
Tracks
Sector
Cylinder
• RandomAccessMemory(RAM)orMainMemory:
• Fast• Randomaccess,byteaddressable
• ~10xfasterforsequentialaccess• ~100,000xfasterforrandomaccess!
• Volatile• Datacanbelostife.g.crashoccurs,powergoesout,etc!
• Expensive• For$100,get16GBofRAMvs.2TBofdisk!
8
Lecture7>Section3>Ourmodel
High-level:Diskvs.MainMemory
Ourmodel:ThreeTypesofRegionsofMemory
1. Local: InourmodeleachprocessinaDBMShasitsownlocalmemory,whereitstoresvaluesthatonlyit“sees”
2. Global:Eachprocesscanreadfrom/writetoshareddatainmainmemory
3. Disk:Globalmemorycanreadfrom/flushtodisk
4. Log:Assumeonstablediskstorage- spansbothmainmemoryanddisk…
Local Global
MainMemory(RAM)
Disk
“Flushing todisk”=writingtodiskfrommainmemory
1 2
3
Lecture7>Section3>Ourmodel
Logisasequence frommainmemory->disk
4
• Keepinmindthetradeoffshereasmotivationforthemechanismsweintroduce
• Mainmemory:fastbutlimitedcapacity,volatile
• Vs.Disk:slowbutlargecapacity,durable
10
Lecture7>Section3>Ourmodel
High-level:Diskvs.MainMemory
Howdoweeffectivelyutilizeboth ensuringcertaincriticalguarantees?
Transactions:BasicDefinition
Atransaction(“TXN”)isasequenceofoneormoreoperations (readsorwrites)whichreflectsasinglereal-worldtransition.
START TRANSACTIONUPDATE ProductSET Price = Price – 1.99WHERE pname = ‘Gizmo’
COMMIT
Lecture7>Section1>TransactionsBasics
Intherealworld,aTXNeitherhappenedcompletelyornotatall
Transactions:BasicDefinition
Atransaction(“TXN”)isasequenceofoneormoreoperations (readsorwrites)whichreflectsasinglereal-worldtransition.
Lecture7>Section1>TransactionsBasics
Intherealworld,aTXNeitherhappenedcompletelyornotatall
Examples:
• Transfermoneybetweenaccounts
• Purchaseagroupofproducts
• Registerforaclass(eitherwaitlistorallocated)
14
TransactionsinSQL
• In“ad-hoc”SQL:• Default:eachstatement=onetransaction
• Inaprogram,multiplestatementscanbegroupedtogetherasatransaction:
Lecture7>Section1>TransactionsBasics
START TRANSACTIONUPDATE Bank SET amount = amount – 100WHERE name = ‘Bob’UPDATE Bank SET amount = amount + 100 WHERE name = ‘Joe’
COMMIT
ModelofTransactionforCS145
Note:For145,weassumethattheDBMSonlyseesreadsandwritestodata
• Usermaydomuchmore
• Inrealsystems,databasesdohavemoreinfo...
Lecture7>Section1>TransactionsBasics
MotivationforTransactionsGroupinguseractions(reads&writes)intotransactionshelpswithtwogoals:
1. Recovery&Durability:KeepingtheDBMSdataconsistentanddurableinthefaceofcrashes,aborts,systemshutdowns,etc.
2. Concurrency: AchievingbetterperformancebyparallelizingTXNswithout creatinganomalies
Lecture7>Section1>Motivation
Thislecture!
Nextlecture
Motivation1.Recovery&Durability ofuserdataisessentialforreliableDBMSusage
• TheDBMSmayexperiencecrashes(e.g.poweroutages,etc.)
• IndividualTXNsmaybeaborted(e.g.bytheuser)
Lecture7>Section1>Motivation:Recovery&Durability
Idea:MakesurethatTXNsareeitherdurablystoredinfull,ornotatall;keeplogtobeableto“roll-back”TXNs
18
Protectionagainstcrashes/aborts
Client 1:INSERT INTO SmallProduct(name, price)
SELECT pname, priceFROM ProductWHERE price <= 0.99
DELETE ProductWHERE price <=0.99
Whatgoeswrong?
Crash/abort!
Lecture7>Section1>Motivation:Recovery&Durability
19
Protectionagainstcrashes/abortsClient 1:
START TRANSACTIONINSERT INTO SmallProduct(name, price)
SELECT pname, priceFROM ProductWHERE price <= 0.99
DELETE ProductWHERE price <=0.99
COMMIT OR ROLLBACK
Nowwe’dbefine!We’llseehow/whythislecture
Lecture7>Section1>Motivation:Recovery&Durability
Motivation2.Concurrent executionofuserprogramsisessentialforgoodDBMSperformance.
• Diskaccessesmaybefrequentandslow- optimizeforthroughput(#ofTXNs),tradeforlatency(timeforanyoneTXN)
• UsersshouldstillbeabletoexecuteTXNsasifinisolation andsuchthatconsistencyismaintained
Idea:HavetheDBMShandlerunningseveraluserTXNsconcurrently,inordertokeepCPUshumming…
Lecture7>Section1>Motivation:Concurrency
21
Multipleusers:singlestatements
Client 1: UPDATE ProductSET Price = Price – 1.99WHERE pname = ‘Gizmo’
Client 2: UPDATE ProductSET Price = Price*0.5WHERE pname=‘Gizmo’
Twomanagersattempttodiscountproductsconcurrently-Whatcouldgowrong?
Lecture7>Section1>Motivation:Concurrency
22
Multipleusers:singlestatementsClient 1: START TRANSACTION
UPDATE ProductSET Price = Price – 1.99WHERE pname = ‘Gizmo’
COMMIT
Client 2: START TRANSACTIONUPDATE ProductSET Price = Price*0.5WHERE pname=‘Gizmo’
COMMIT
Nowworkslikeacharm- we’llseehow/whynextlecture…
Lecture7>Section1>Motivation:Concurrency
Whatyouwilllearnaboutinthissection
1. Atomicity
2. Consistency
3. Isolation
4. Durability
24
Lecture7>Section2
25
TransactionProperties:ACID
• Atomic• Stateshowseitheralltheeffectsoftxn,ornoneofthem
• Consistent• Txn movesfromastatewhereintegrityholds,toanotherwhereintegrityholds
• Isolated• Effectoftxns isthesameastxns runningoneafteranother(ie lookslikebatchmode)
• Durable• Onceatxn hascommitted,itseffectsremaininthedatabase
ACIDcontinuestobeasourceofgreatdebate!
Lecture7>Section2
26
ACID:Atomicity
• TXN’sactivitiesareatomic:allornothing
• Intuitively:intherealworld,atransactionissomethingthatwouldeitheroccurcompletely ornotatall
• TwopossibleoutcomesforaTXN
• Itcommits:allthechangesaremade
• Itaborts:nochangesaremade
Lecture7>Section2>Atomicity
27
ACID:Consistency
• Thetablesmustalwayssatisfyuser-specifiedintegrityconstraints• Examples:
• Accountnumberisunique• Stockamountcan’tbenegative• Sumofdebitsandofcredits is0
• Howconsistencyisachieved:• Programmermakessureatxn takesaconsistentstatetoaconsistentstate• Systemmakessurethatthetxn isatomic
Lecture7>Section2>Consistency
28
ACID:Isolation
• Atransactionexecutesconcurrentlywithothertransactions
• Isolation:theeffectisasifeachtransactionexecutesinisolation oftheothers.
• E.g.Shouldnotbeabletoobservechangesfromothertransactionsduringtherun
Lecture7>Section2>Isolation
29
ACID:Durability
• TheeffectofaTXNmustcontinuetoexist(“persist”)aftertheTXN
• Andafterthewholeprogramhasterminated• Andeveniftherearepowerfailures,crashes,etc.• Andetc…
• Means:WritedatatodiskChangeonthehorizon?Non-VolatileRam(NVRam).Byteaddressable.
Lecture7>Section2>Durability
ChallengesforACIDproperties
• Inspiteoffailures:Powerfailures,butnotmediafailures
• Usersmayaborttheprogram:needto“rollbackthechanges”• Needtolog whathappened
• Manyusersexecutingconcurrently• Canbesolvedvialocking(we’llseethisnextlecture!)
Andallthiswith…Performance!!
Lecture7>Section2
Thislecture
Nextlecture
ANote:ACIDiscontentious!
• ManydebatesoverACID,bothhistoricallyand currently
• Manynewer“NoSQL”DBMSsrelaxACID
• Inturn,now“NewSQL”reintroducesACIDcompliancetoNoSQL-styleDBMSs…
Lecture7>Section2
ACIDisanextremelyimportant&successfulparadigm,butstilldebated!
Goalforthislecture:EnsuringAtomicity&Durability• Atomicity:
• TXNsshouldeitherhappencompletelyornotatall
• Ifabort/crashduringTXN,no effectsshouldbeseen
32
Lecture7>Section3>Motivation&basics
ACID
TXN1
TXN2
No changespersisted
All changespersisted
We’llfocusonhowtoaccomplishatomicity(vialogging)
Crash/abort
• Durability:• IfDBMSstopsrunning,changesduetocompletedTXNsshouldallpersist
• Juststoreonstabledisk
TheLog• Isalistofmodifications
• Logisduplexedandarchived onstablestorage.
• Canforcewrite entriestodisk• Apagegoestodisk.
• Alllogactivitieshandledtransparently theDBMS.
Assumewedon’tloseit!
Lecture7>Section3>Motivation&basics
BasicIdea:(Physical)Logging• RecordUNDOinformationforeveryupdate!
• Sequentialwritestolog• Minimalinfo(diff)writtentolog
• Thelog consistsofanorderedlistofactions• Logrecordcontains:
<XID,location,olddata,newdata>
ThisissufficienttoUNDOanytransaction!
Lecture7>Section3>Motivation&basics
Whydoweneedloggingforatomicity?• Couldn’twejustwriteTXNtodiskonly oncewholeTXNcomplete?
• Then,ifabort/crashandTXNnotcomplete,ithasnoeffect- atomicity!• Withunlimitedmemoryandtime,thiscouldwork…
• However,weneedtologpartialresultsofTXNs becauseof:• Memoryconstraints(enoughspaceforfullTXN??)• Timeconstraints(whatifoneTXNtakesverylong?)
Weneedtowritepartialresultstodisk!…Andsoweneedalog tobeabletoundo thesepartialresults!
Lecture7>Section3>Motivation&basics
Apictureoflogging
DataonDisk
MainMemory
LogonDisk
LogT A=0
B=5
A=0
T:R(A),W(A)
Lecture7>Section3>Loggingcommitprotocol
Apictureoflogging
DataonDisk
MainMemory
LogonDisk
LogT A=1
B=5
A=0
T:R(A),W(A)A:0à1
Lecture7>Section3>Loggingcommitprotocol
Apictureoflogging
DataonDisk
MainMemory
LogonDisk
LogT A=1
B=5
A=0
T:R(A),W(A)A:0à1
Lecture7>Section3>Loggingcommitprotocol
Operationrecordedinloginmainmemory!
Whatisthecorrectwaytowritethisalltodisk?• We’lllookattheWrite-AheadLogging(WAL)protocol
• We’llseewhyitworksbylookingatotherprotocolswhichareincorrect!
42
Remember:Keyideaistoensuredurabilitywhilemaintainingourabilityto“undo”!
TransactionCommitProcess
1. FORCEWritecommit recordtolog
2. AlllogrecordsuptolastupdatefromthisTXareFORCED
3. Commit()returns
Transactioniscommittedoncecommitlogrecordisonstablestorage
Lecture7>Section3>Loggingcommitprotocol
IncorrectCommitProtocol#1
DataonDisk
MainMemory
LogonDisk
LogT A=1
B=5
A=0
T:R(A),W(A) A:0à1
Lecture7>Section3>Loggingcommitprotocol
Let’strycommittingbefore we’vewritteneitherdataorlogtodisk…
Ifwecrashnow,isTdurable?
OK,Commit!
LostT’supdate!
IncorrectCommitProtocol#2
DataonDisk
MainMemory
LogonDisk
LogT A=1
B=5
A=0
T:R(A),W(A) A:0à1
Lecture7>Section3>Loggingcommitprotocol
Let’strycommittingafter we’vewrittendatabutbefore we’vewrittenlogtodisk…
Ifwecrashnow,isTdurable?Yes!Except…
OK,Commit!
HowdoweknowwhetherTwascommitted??
Write-aheadLogging(WAL)CommitProtocol
DataonDisk
MainMemory
LogonDisk
LogT A=1
B=5
A=0
T:R(A),W(A) A:0à1
Lecture7>Section3>Loggingcommitprotocol
Thistime,let’strycommittingafter we’vewrittenlogtodiskbutbefore we’vewrittendatatodisk…thisisWAL!
Ifwecrashnow,isTdurable?
OK,Commit!
Write-aheadLogging(WAL)CommitProtocol
DataonDisk
MainMemory
LogonDisk
T
A=0
T:R(A),W(A)
A:0à1
Lecture7>Section3>Loggingcommitprotocol
Thistime,let’strycommittingafter we’vewrittenlogtodiskbutbefore we’vewrittendatatodisk…thisisWAL!
Ifwecrashnow,isTdurable?
OK,Commit!
USETHELOG!A=1
Write-AheadLogging(WAL)
• DBusesWrite-AheadLogging(WAL) Protocol:
1. Mustforcelogrecord foranupdatebefore thecorrespondingdatapagegoestostorage
2. MustwritealllogrecordsforaTXbefore commit
Lecture7>Section3>Loggingcommitprotocol
Eachupdateislogged!Whynotreads?
à Atomicity
à Durability
LoggingSummary
• IfDBsaysTXcommits,TXeffectremains afterdatabasecrash
• DBcanundoactionsandhelpuswithatomicity
• Thisisonlyhalfthestory…
Lecture7>Section3>Loggingcommitprotocol
Today’sLecture
1. Concurrency,scheduling&anomalies
2. Locking:2PL,conflictserializability,deadlockdetection
53
Lecture8
Whatyouwilllearnaboutinthissection
1. Interleaving&scheduling
2. Conflict&anomalytypes
3. ACTIVITY:TXNviewer
55
Lecture8>Section1
Concurrency:Isolation&Consistency
Lecture8>Section1>Interleaving&scheduling
• TheDBMSmusthandleconcurrencysuchthat…
1. Isolation ismaintained:UsersmustbeabletoexecuteeachTXNasiftheyweretheonlyuser• DBMShandlesthedetailsofinterleaving variousTXNs
2. Consistency ismaintained:TXNsmustleavetheDBinaconsistentstate• DBMShandlesthedetailsofenforcingintegrityconstraints
ACID
ACID
Example- considertwoTXNs:
Lecture8>Section1>Interleaving&scheduling
T1: START TRANSACTIONUPDATE AccountsSET Amt = Amt + 100WHERE Name = ‘A’
UPDATE AccountsSET Amt = Amt - 100WHERE Name = ‘B’
COMMIT
T2: START TRANSACTIONUPDATE AccountsSET Amt = Amt * 1.06
COMMIT
T1transfers$100fromB’saccounttoA’saccount
T2creditsbothaccountswitha6%interestpayment
Example- considertwoTXNs:
Lecture8>Section1>Interleaving&scheduling
T1transfers$100fromB’saccounttoA’saccount
T2creditsbothaccountswitha6%interestpayment
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
Time
WecanlookattheTXNsinatimelineview- serialexecution:
Example- considertwoTXNs:
Lecture8>Section1>Interleaving&scheduling
T1transfers$100fromB’saccounttoA’saccount
T2creditsbothaccountswitha6%interestpayment
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
Time
TheTXNscouldoccurineitherorder…DBMSallows!
Example- considertwoTXNs:
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
Time
TheDBMScanalsointerleave theTXNs
T2creditsA’saccountwith6%interestpayment,thenT1transfers$100toA’saccount…
T2creditsB’saccountwitha6%interestpayment,thenT1transfers$100fromB’saccount…
Example- considertwoTXNs:
Lecture8>Section1>Interleaving&scheduling
Whatgoeswronghere??
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
Time
TheDBMScanalsointerleave theTXNs
Recall:ThreeTypesofRegionsofMemory
1. Local: InourmodeleachprocessinaDBMShasitsownlocalmemory,whereitstoresvaluesthatonlyit“sees”
2. Global:Eachprocesscanreadfrom/writetoshareddatainmainmemory
3. Disk:Globalmemorycanreadfrom/flushtodisk
4. Log:Assumeonstablediskstorage- spansbothmainmemoryanddisk…
Local Global
MainMemory(RAM)
Disk
“Flushing todisk”=writingtodisk.
1 2
3
Lecture8>Section1>Interleaving&scheduling
Logisasequence frommainmemory->disk
4
WhyInterleaveTXNs?
• InterleavingTXNsmightleadtoanomalousoutcomes…whydoit?
• Severalimportantreasons:• IndividualTXNsmightbeslow- don’twanttoblockotherusersduring!
• Diskaccessmaybeslow- letsomeTXNsuseCPUswhileothersaccessingdisk!
63
Lecture8>Section1>Interleaving&scheduling
Allconcernlargedifferencesinperformance
Interleaving&Isolation
• TheDBMShasfreedomtointerleaveTXNs
• However,itmustpickaninterleavingorschedulesuchthatisolationandconsistencyaremaintained
• Mustbeasif theTXNshadexecutedserially!
64
Lecture8>Section1>Interleaving&scheduling
DBMSmustpickaschedulewhichmaintainsisolation&consistency
“Withgreatpowercomesgreatresponsibility”
ACID
Schedulingexamples
65
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
A B
$50 $200
A B
$159 $106
A B
$159 $106
StartingBalance
Sameresult!
SerialscheduleT1,T2:
InterleavedscheduleA:
Schedulingexamples
66
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
A B
$50 $200
A B
$159 $106
A B
$159 $112
StartingBalance
DifferentresultthanserialT1,T2!
SerialscheduleT1,T2:
InterleavedscheduleB:
Schedulingexamples
67
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
A B
$50 $200
A B
$153 $112
A B
$159 $112
StartingBalance
DifferentresultthanserialT2,T1ALSO!
SerialscheduleT2,T1:
InterleavedscheduleB:
Schedulingexamples
68
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
Thisscheduleisdifferentthananyserialorder! Wesaythatitisnot
serializable
InterleavedscheduleB:
Scheduling Definitions• Aserialschedule isonethatdoesnotinterleavetheactionsofdifferenttransactions
• AandBareequivalentschedules if, foranydatabasestate,theeffectonDBofexecutingAisidenticaltotheeffectofexecutingB
• Aserializableschedule isa schedulethatisequivalenttosome serialexecutionofthetransactions.
Theword“some”makesthisdefinitionpowerful& tricky!
Lecture8>Section1>Interleaving&scheduling
Serializable?
70
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
SameasaserialscheduleforallpossiblevaluesofA,B=serializable
Serialschedules:
A B
T1,T2 1.06*(A+100) 1.06*(B-100)
T2,T1 1.06*A+100 1.06*B- 100
A B
1.06*(A+100) 1.06*(B-100)
Serializable?
71
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
Notequivalent toanyserializableschedule =notserializable
Serialschedules:
A B
T1,T2 1.06*(A+100) 1.06*(B-100)
T2,T1 1.06*A+100 1.06*B- 100
A B
1.06*(A+100) 1.06*B- 100
Whatelsecangowrongwithinterleaving?
• Variousanomalieswhichbreakisolation/serializability
• Oftenreferredtobyname…
• Occurbecauseof/withcertain“conflicts”betweeninterleavedTXNs
72
Lecture8>Section1>Interleaving&scheduling
TheDBMS’sviewoftheschedule
73
Lecture8>Section1>Interleaving&scheduling
T1
T2
A+=100 B -=100
A*=1.06 B *=1.06
T1
T2
R(A)
R(A)
W(A)
W(A) R(B) W(B)
R(B) W(B)
EachactionintheTXNsreadsavaluefromglobalmemory andthenwritesonebacktoit
Schedulingordermatters!
ConflictTypes
• Thus,therearethreetypesofconflicts:• Read-Writeconflicts(RW)• Write-Readconflicts(WR)• Write-Writeconflicts(WW)
Whyno“RRConflict”?
Lecture8>Section1>Interleaving&scheduling
Twoactionsconflict iftheyarepartofdifferentTXNs,involvethesamevariable,andatleastoneofthemisawrite
Interleavinganomaliesoccurwith/becauseoftheseconflictsbetweenTXNs (buttheseconflictscanoccurwithoutcausinganomalies!)
Seenextsectionformore!
Occurringwith/becauseofaRWconflict
Lecture8>Section1>Interleaving&scheduling
ClassicAnomalieswithInterleavedExecution
“Unrepeatableread”:
T1
T2
R(A) R(A)
1. T1 reads somedata fromA
2. T2 writes toA
3. Then,T1 readsfromAagainandnowgetsadifferent/inconsistentvalue
R(A) W(A) C
Example:
Occurringwith/becauseofaWRconflict
Lecture8>Section1>Interleaving&scheduling
ClassicAnomalieswithInterleavedExecution
“Dirtyread”/Readinguncommitteddata:
T1
T2
W(A) A
1. T1 writes somedata toA
2. T2 reads fromA,thenwritesbacktoA&commits
3. T1 thenaborts- nowT2’sresultisbasedonanobsolete/inconsistentvalue
R(A) W(A) C
Example:
Lecture8>Section1>Interleaving&scheduling
ClassicAnomalieswithInterleavedExecution
“Inconsistentread”/Readingpartialcommits:
T1
T2
W(A)
1. T1 writes somedata toA
2. T2 reads fromAandB,andthenwritessomevaluewhichdependsonA&B
3. T1 thenwritestoB- nowT2’sresultisbasedonanincompletecommit
Example:
W(B) C
R(A) CR(B) W(C=A*B)
Again,occurringbecauseofaWRconflict
Lecture8>Section1>Interleaving&scheduling
ClassicAnomalieswithInterleavedExecution
Partially-lostupdate:
T1
T2
W(A)
1. T1 blindwrites somedata toA
2. T2 blindwrites toAandB
3. T1 thenblindwrites toB;nowwehaveT2’svalueforBandT1’svalueforA- notequivalenttoanyserialschedule!
Example:
W(B) C
W(A) CW(B)
OccurringbecauseofaWWconflict
Whatyouwilllearnaboutinthissection
1. RECAP:Concurrency
2. ConflictSerializability
3. DAGs&TopologicalOrderings
4. Strict2PL
5. Deadlocks
81
Lecture8>Section2
Recall:ConcurrencyasInterleavingTXNs
• Forourpurposes,havingTXNsoccurconcurrentlymeansinterleavingtheircomponentactions(R/W)
82
Lecture8>Section2>Concurrency
Wecalltheparticularorderofinterleavingaschedule
T1T2
R(A) R(B)W(A) W(B)
SerialSchedule:
R(A) R(B)W(A) W(B)
T1T2
R(A) R(B)W(A) W(B)
InterleavedSchedule:
R(A) R(B)W(A) W(B)
Recall:“Good”vs.“bad”schedules
83
Wewanttodevelopwaysofdiscerning“good”vs.“bad”schedules
SerialSchedule:
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
X
InterleavedSchedules:
Why?
Lecture8>Section2>Concurrency
WaysofDefining“Good”vs.“Bad”Schedules• Recallfromlasttime:wecallascheduleserializable ifitisequivalenttosome serialschedule
• Weusedthisasanotionofa“good”interleavedschedule,sinceaserializableschedulewillmaintainisolation&consistency
• Now,we’lldefineastricter,butveryusefulvariant:
• Conflictserializability We’llneedtodefineconflicts first..
Lecture8>Section2>Concurrency
Conflicts
Twoactionsconflict iftheyarepartofdifferentTXNs,involvethesamevariable,andatleastoneofthemisawrite
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)W-RConflict
W-WConflict
Lecture8>Section2>ConflictSerializability
Conflicts
Twoactionsconflict iftheyarepartofdifferentTXNs,involvethesamevariable,andatleastoneofthemisawrite
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
All“conflicts”!
Lecture8>Section2>ConflictSerializability
ConflictSerializability• Twoschedulesareconflictequivalentif:
• TheyinvolvethesameactionsofthesameTXNs
• Everypairofconflictingactions oftwoTXNsareorderedinthesameway
• ScheduleSisconflictserializableifSisconflictequivalent tosomeserialschedule
Conflictserializable⇒ serializableSoifwehaveconflictserializable,wehaveconsistency&isolation!
Lecture8>Section2>ConflictSerializability
Recall:“Good”vs.“bad”schedules
88
Conflictserializability alsoprovidesuswithanoperativenotionof“good”vs.“bad”schedules!
SerialSchedule:
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
X
InterleavedSchedules:
Notethatinthe“bad”schedule,theorderofconflictingactionsisdifferentthantheabove(orany)serialschedule!
Lecture8>Section2>ConflictSerializability
Note:Conflictsvs.Anomalies
• Conflicts arethingswetalkabouttohelpuscharacterizedifferentschedules
• Presentinboth“good”and“bad”schedules
• Anomalies areinstanceswhereisolationand/orconsistencyisbrokenbecauseofa“bad”schedule
• Weoftencharacterizedifferentanomalytypesbywhattypesofconflictspredicatedthem
Lecture8>Section2>ConflictSerializability
TheConflictGraph
• Let’snowconsiderlookingatconflictsattheTXNlevel
• ConsideragraphwherethenodesareTXNs,andthereisanedgefromTi àTj ifanyactionsinTi precedeandconflictwith anyactionsinTj
T1 T2
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
Lecture8>Section2>ConflictSerializability
91
SerialSchedule:
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
T1
T2
R(A) R(B)W(A) W(B)
R(A) R(B)W(A) W(B)
X
InterleavedSchedules:
Whatcanwesayabout“good”vs.“bad”conflictgraphs?
Abitcomplicated…
Lecture8>Section2>ConflictSerializability
92
SerialSchedule:
X
InterleavedSchedules:
Whatcanwesayabout“good”vs.“bad”conflictgraphs?
T1 T2 T1 T2
T1 T2
Theorem:Scheduleisconflictserializable ifandonlyifitsconflictgraphisacyclic
Simple!
Lecture8>Section2>ConflictSerializability
DAGs&TopologicalOrderings
• Atopologicalorderingofadirectedgraphisalinearorderingofitsverticesthatrespectsallthedirectededges
• Adirectedacyclic graph(DAG)alwayshasoneormoretopologicalorderings
• (Andthereexistsatopologicalorderingifandonlyiftherearenodirectedcycles)
Lecture8>Section2>Topologicalorderings
DAGs&TopologicalOrderings
• Ex:Whatisonepossibletopologicalorderinghere?
1
32
0
Ex:0,1,2,3(or:0,1,3,2)
Lecture8>Section2>Topologicalorderings
DAGs&TopologicalOrderings
• Ex:Whatisonepossibletopologicalorderinghere?
1
32
0
Thereisnone!
Lecture8>Section2>Topologicalorderings
Connectiontoconflictserializability
• Intheconflictgraph,atopologicalorderingofnodescorrespondstoaserialorderingofTXNs
• Thusanacyclic conflictgraphà conflictserializable!
Theorem:Scheduleisconflictserializable ifandonlyifitsconflictgraphisacyclic
Lecture8>Section2>Topologicalorderings
StrictTwo-PhaseLocking
• Weconsiderlocking- specifically,stricttwo-phaselocking- asawaytodealwithconcurrency,becauseisguaranteesconflictserializability(ifitcompletes- seeupcoming…)
• Also(conceptually)straightforwardtoimplement,andtransparenttotheuser!
Lecture8>Section2>Strict2PL
StrictTwo-phaseLocking(Strict2PL)Protocol:
TXNsobtain:
• AnX(exclusive)lockonobjectbeforewriting.
• IfaTXNholds,nootherTXNcangeta lock(SorX)onthatobject.
• AnS(shared)lockonobjectbeforereading
• IfaTXNholds,nootherTXNcangetanXlock onthatobject
• AlllocksheldbyaTXNarereleasedwhenTXNcompletes.
Note:Terminologyhere- “exclusive”,“shared”- meanttobeintuitive- notricks!
Lecture8>Section2>Strict2PL
Pictureof2-PhaseLocking(2PL)
TimeStrict2PL
0locks
#LockstheTXNhas
LockAcquisition
LockReleaseOnTXNcommit!
Lecture8>Section2>Strict2PL
Strict2PLTheorem: Strict2PLallowsonlyscheduleswhosedependencygraphisacyclic
Therefore,Strict2PLonlyallowsconflictserializable⇒ serializableschedules
ProofIntuition:Instrict2PL,ifthereisanedgeTi à Tj (i.e.Ti andTjconflict)thenTj needstowaituntilTi isfinished– socannothaveanedgeTj à Ti
Lecture8>Section2>Strict2PL
Strict2PL
• Ifaschedulefollowsstrict2PL andlocking,itisconflictserializable…
• …andthusserializable• …andthusmaintainsisolation&consistency!
• Notallserializableschedulesareallowedbystrict2PL.
• Solet’susestrict2PL,whatcouldgowrong?
Lecture8>Section2>Strict2PL
DeadlockDetection:Example
First,T1 requestsasharedlockonAtoreadfromit
T1T2
S(A) R(A)
Waits-forgraph:
T1 T2
Lecture8>Section2>Deadlocks
DeadlockDetection:Example
Next,T2 requestsasharedlockonBtoreadfromit
T1T2 S(B) R(B)
S(A) R(A)
Waits-forgraph:
T1 T2
Lecture8>Section2>Deadlocks
DeadlockDetection:Example
T2 thenrequestsanexclusivelockonAtowritetoit- nowT2iswaitingonT1…
T1T2 X(A)S(B) R(B)
S(A) R(A)
Waits-forgraph:
T1 T2
W(A)Waiting…
Lecture8>Section2>Deadlocks
DeadlockDetection:Example
Finally,T1 requestsanexclusivelockonBtowritetoit- nowT1iswaitingonT2…DEADLOCK!
T1T2
X(B)
X(A)S(B) R(B)
S(A) R(A)
Waits-forgraph:
T1 T2
W(A)
W(B)
Cycle=DEADLOCK
Waiting…
Waiting…
Lecture8>Section2>Deadlocks
ERROR: deadlock detectedDETAIL: Process 321 waits for ExclusiveLock on tuple of relation 20 of database 12002; blocked by process 4924.Process 404 waits for ShareLock on transaction 689; blocked by process 552.HINT: See server log for query details.
Theproblem?Deadlock!??!
NB:Alsomoviecalledwedlock(deadlock)setinafuturisticprison…Ihaven’tseeneitherofthem…
T1 T2
Lecture8>Section2>Deadlocks
Deadlocks
• Deadlock:Cycleoftransactionswaitingforlockstobereleasedbyeachother.
• Twowaysofdealingwithdeadlocks:
1. Deadlockprevention
2. Deadlockdetection
Lecture8>Section2>Deadlocks
DeadlockDetection
• Createthewaits-forgraph:
• Nodesaretransactions
• ThereisanedgefromTi à Tj ifTi iswaitingforTj toreleasealock
• Periodicallycheckfor(andbreak)cyclesinthewaits-forgraph
Lecture8>Section2>Deadlocks
Summary
• ConcurrencyachievedbyinterleavingTXNssuchthatisolation&consistencyaremaintained
• Weformalizedanotionofserializability thatcapturedsucha“good”interleavingschedule
• Wedefinedconflictserializability,whichimpliesserializability
• Lockingallowsonlyconflictserializableschedules• Iftheschedulecompletes…(itmaydeadlock!)
Lecture8>Section2