Lectures 7 & 8: Transactions - web.stanford.eduweb.stanford.edu/class/cs145/lectures/lecture-8/Lecture_8_TXNs.pdfWhat you will learn about in this section 1. Our “model” of the

Lectures7&8:Transactions

Lectures8&9

Goalsforthispairoflectures

• Transactions areaprogrammingabstractionthatenablestheDBMStohandlerecovery andconcurrency forusers.

• Application:Transactionsarecriticalforusers• Evencasualusersofdataprocessingsystems!

• Fundamentals:Thebasicsofhow TXNswork• Transactionprocessingispartofthedebatearoundnewdataprocessingsystems

• GiveyouenoughinformationtounderstandhowTXNswork,andthemainconcernswithusingthem

Lectures7&8

Lecture7:IntrotoTransactions&Logging

Lecture7

Today’sLecture

1. Transactions

2. PropertiesofTransactions:ACID

3. Logging

4

Lecture7

1.Transactions

5

Lecture7>Section1

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



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


Logisasequence frommainmemory->disk

4

• Keepinmindthetradeoffshereasmotivationforthemechanismsweintroduce

• Mainmemory:fastbutlimitedcapacity,volatile

• Vs.Disk:slowbutlargecapacity,durable

10



Howdoweeffectivelyutilizeboth ensuringcertaincriticalguarantees?

Transactions

11

Lecture7>Section1>TransactionsBasics

Transactions:BasicDefinition

Atransaction(“TXN”)isasequenceofoneormoreoperations (readsorwrites)whichreflectsasinglereal-worldtransition.

START TRANSACTIONUPDATE ProductSET Price = Price – 1.99WHERE pname = ‘Gizmo’

COMMIT


Intherealworld,aTXNeitherhappenedcompletelyornotatall

Transactions:BasicDefinition

Atransaction(“TXN”)isasequenceofoneormoreoperations (readsorwrites)whichreflectsasinglereal-worldtransition.


Intherealworld,aTXNeitherhappenedcompletelyornotatall

Examples:

• Transfermoneybetweenaccounts

• Purchaseagroupofproducts

• Registerforaclass(eitherwaitlistorallocated)

14

TransactionsinSQL

• In“ad-hoc”SQL:• Default:eachstatement=onetransaction

• Inaprogram,multiplestatementscanbegroupedtogetherasatransaction:


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...


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!


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


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?


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…


2.PropertiesofTransactions

23

Lecture7>Section2


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!


BasicIdea:(Physical)Logging• RecordUNDOinformationforeveryupdate!

• Sequentialwritestolog• Minimalinfo(diff)writtentolog

• Thelog consistsofanorderedlistofactions• Logrecordcontains:

<XID,location,olddata,newdata>

ThisissufficienttoUNDOanytransaction!


Whydoweneedloggingforatomicity?• Couldn’twejustwriteTXNtodiskonly oncewholeTXNcomplete?

• Then,ifabort/crashandTXNnotcomplete,ithasnoeffect- atomicity!• Withunlimitedmemoryandtime,thiscouldwork…

• However,weneedtologpartialresultsofTXNs becauseof:• Memoryconstraints(enoughspaceforfullTXN??)• Timeconstraints(whatifoneTXNtakesverylong?)

Weneedtowritepartialresultstodisk!…Andsoweneedalog tobeabletoundo thesepartialresults!


3.Atomicity&DurabilityviaLogging

36

Lecture7>Section3


1. Logging:Ananimationofcommitprotocols

37

Lecture7>Section3

APictureofLogging

Lecture7>Section3>Loggingcommitprotocol

Apictureoflogging

DataonDisk

MainMemory

LogonDisk

LogT A=0

B=5

A=0

T:R(A),W(A)


Apictureoflogging

DataonDisk

MainMemory

LogonDisk

LogT A=1

B=5

A=0

T:R(A),W(A)A:0à1


Apictureoflogging

DataonDisk

MainMemory

LogonDisk

LogT A=1

B=5

A=0

T:R(A),W(A)A:0à1


Operationrecordedinloginmainmemory!

Whatisthecorrectwaytowritethisalltodisk?• We’lllookattheWrite-AheadLogging(WAL)protocol

• We’llseewhyitworksbylookingatotherprotocolswhichareincorrect!

42

Remember:Keyideaistoensuredurabilitywhilemaintainingourabilityto“undo”!

Write-AheadLogging(WAL)TXNCommitProtocol


TransactionCommitProcess

1. FORCEWritecommit recordtolog

2. AlllogrecordsuptolastupdatefromthisTXareFORCED

3. Commit()returns

Transactioniscommittedoncecommitlogrecordisonstablestorage


IncorrectCommitProtocol#1

DataonDisk

MainMemory

LogonDisk

LogT A=1

B=5

A=0

T:R(A),W(A) A:0à1


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


Let’strycommittingafter we’vewrittendatabutbefore we’vewrittenlogtodisk…

Ifwecrashnow,isTdurable?Yes!Except…

OK,Commit!

HowdoweknowwhetherTwascommitted??

ImprovedCommitProtocol(WAL)


Write-aheadLogging(WAL)CommitProtocol

DataonDisk

MainMemory

LogonDisk

LogT A=1

B=5

A=0

T:R(A),W(A) A:0à1


Thistime,let’strycommittingafter we’vewrittenlogtodiskbutbefore we’vewrittendatatodisk…thisisWAL!


OK,Commit!

Write-aheadLogging(WAL)CommitProtocol

DataonDisk

MainMemory

LogonDisk

T

A=0

T:R(A),W(A)

A:0à1


Thistime,let’strycommittingafter we’vewrittenlogtodiskbutbefore we’vewrittendatatodisk…thisisWAL!


OK,Commit!

USETHELOG!A=1

Write-AheadLogging(WAL)

• DBusesWrite-AheadLogging(WAL) Protocol:

1. Mustforcelogrecord foranupdatebefore thecorrespondingdatapagegoestostorage

2. MustwritealllogrecordsforaTXbefore commit


Eachupdateislogged!Whynotreads?

à Atomicity

à Durability

LoggingSummary

• IfDBsaysTXcommits,TXeffectremains afterdatabasecrash

• DBcanundoactionsandhelpuswithatomicity

• Thisisonlyhalfthestory…


Lecture8:Concurrency&Locking

Lecture8

Today’sLecture

1. Concurrency,scheduling&anomalies

2. Locking:2PL,conflictserializability,deadlockdetection

53

Lecture8

1.Concurrency,Scheduling&Anomalies

54

Lecture8>Section1


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:


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





T1

T2

A+=100 B -=100

A*=1.06 B *=1.06

Time

WecanlookattheTXNsinatimelineview- serialexecution:





T1

T2

A+=100 B -=100

A*=1.06 B *=1.06

Time

TheTXNscouldoccurineitherorder…DBMSallows!



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…



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


Logisasequence frommainmemory->disk

4

WhyInterleaveTXNs?

• InterleavingTXNsmightleadtoanomalousoutcomes…whydoit?

• Severalimportantreasons:• IndividualTXNsmightbeslow- don’twanttoblockotherusersduring!

• Diskaccessmaybeslow- letsomeTXNsuseCPUswhileothersaccessingdisk!

63


Allconcernlargedifferencesinperformance

Interleaving&Isolation

• TheDBMShasfreedomtointerleaveTXNs

• However,itmustpickaninterleavingorschedulesuchthatisolationandconsistencyaremaintained

• Mustbeasif theTXNshadexecutedserially!

64


DBMSmustpickaschedulewhichmaintainsisolation&consistency

“Withgreatpowercomesgreatresponsibility”

ACID

Schedulingexamples

65


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


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!


InterleavedscheduleB:

Schedulingexamples

67


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!



Schedulingexamples

68


T1

T2

A+=100 B -=100

A*=1.06 B *=1.06

Thisscheduleisdifferentthananyserialorder! Wesaythatitisnot

serializable


Scheduling Definitions• Aserialschedule isonethatdoesnotinterleavetheactionsofdifferenttransactions

• AandBareequivalentschedules if, foranydatabasestate,theeffectonDBofexecutingAisidenticaltotheeffectofexecutingB

• Aserializableschedule isa schedulethatisequivalenttosome serialexecutionofthetransactions.

Theword“some”makesthisdefinitionpowerful& tricky!


Serializable?

70


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


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


TheDBMS’sviewoftheschedule

73


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”?


Twoactionsconflict iftheyarepartofdifferentTXNs,involvethesamevariable,andatleastoneofthemisawrite

Interleavinganomaliesoccurwith/becauseoftheseconflictsbetweenTXNs (buttheseconflictscanoccurwithoutcausinganomalies!)

Seenextsectionformore!

Occurringwith/becauseofaRWconflict


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



“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:



“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



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

Activity-8-1.ipynb

79

Lecture8>Section1 >ACTIVITY

2.ConflictSerializability,Locking&Deadlock

80

Lecture8>Section2


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?


WaysofDefining“Good”vs.“Bad”Schedules• Recallfromlasttime:wecallascheduleserializable ifitisequivalenttosome serialschedule

• Weusedthisasanotionofa“good”interleavedschedule,sinceaserializableschedulewillmaintainisolation&consistency

• Now,we’lldefineastricter,butveryusefulvariant:

• Conflictserializability We’llneedtodefineconflicts first..


Conflicts


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


T1

T2

R(A) R(B)W(A) W(B)

R(A) R(B)W(A) W(B)

All“conflicts”!


ConflictSerializability• Twoschedulesareconflictequivalentif:

• TheyinvolvethesameactionsofthesameTXNs

• Everypairofconflictingactions oftwoTXNsareorderedinthesameway

• ScheduleSisconflictserializableifSisconflictequivalent tosomeserialschedule

Conflictserializable⇒ serializableSoifwehaveconflictserializable,wehaveconsistency&isolation!


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


Notethatinthe“bad”schedule,theorderofconflictingactionsisdifferentthantheabove(orany)serialschedule!


Note:Conflictsvs.Anomalies

• Conflicts arethingswetalkabouttohelpuscharacterizedifferentschedules

• Presentinboth“good”and“bad”schedules

• Anomalies areinstanceswhereisolationand/orconsistencyisbrokenbecauseofa“bad”schedule

• Weoftencharacterizedifferentanomalytypesbywhattypesofconflictspredicatedthem


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)


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


Whatcanwesayabout“good”vs.“bad”conflictgraphs?

Abitcomplicated…


92

SerialSchedule:

X


Whatcanwesayabout“good”vs.“bad”conflictgraphs?

T1 T2 T1 T2

T1 T2

Theorem:Scheduleisconflictserializable ifandonlyifitsconflictgraphisacyclic

Simple!


Let’sunpackthisnotionofacyclicconflictgraphs…


DAGs&TopologicalOrderings

• Atopologicalorderingofadirectedgraphisalinearorderingofitsverticesthatrespectsallthedirectededges

• Adirectedacyclic graph(DAG)alwayshasoneormoretopologicalorderings

• (Andthereexistsatopologicalorderingifandonlyiftherearenodirectedcycles)

Lecture8>Section2>Topologicalorderings


• Ex:Whatisonepossibletopologicalorderinghere?

1

32

0

Ex:0,1,2,3(or:0,1,3,2)



• Ex:Whatisonepossibletopologicalorderinghere?

1

32

0

Thereisnone!


Connectiontoconflictserializability

• Intheconflictgraph,atopologicalorderingofnodescorrespondstoaserialorderingofTXNs

• Thusanacyclic conflictgraphà conflictserializable!

Theorem:Scheduleisconflictserializable ifandonlyifitsconflictgraphisacyclic


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!


Pictureof2-PhaseLocking(2PL)

TimeStrict2PL

0locks

#LockstheTXNhas

LockAcquisition

LockReleaseOnTXNcommit!


Strict2PLTheorem: Strict2PLallowsonlyscheduleswhosedependencygraphisacyclic

Therefore,Strict2PLonlyallowsconflictserializable⇒ serializableschedules

ProofIntuition:Instrict2PL,ifthereisanedgeTi à Tj (i.e.Ti andTjconflict)thenTj needstowaituntilTi isfinished– socannothaveanedgeTj à Ti


Strict2PL

• Ifaschedulefollowsstrict2PL andlocking,itisconflictserializable…

• …andthusserializable• …andthusmaintainsisolation&consistency!

• Notallserializableschedulesareallowedbystrict2PL.

• Solet’susestrict2PL,whatcouldgowrong?


DeadlockDetection:Example

First,T1 requestsasharedlockonAtoreadfromit

T1T2

S(A) R(A)

Waits-forgraph:

T1 T2

Lecture8>Section2>Deadlocks


Next,T2 requestsasharedlockonBtoreadfromit

T1T2 S(B) R(B)

S(A) R(A)

Waits-forgraph:

T1 T2



T2 thenrequestsanexclusivelockonAtowritetoit- nowT2iswaitingonT1…

T1T2 X(A)S(B) R(B)

S(A) R(A)

Waits-forgraph:

T1 T2

W(A)Waiting…



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…


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


Deadlocks

• Deadlock:Cycleoftransactionswaitingforlockstobereleasedbyeachother.

• Twowaysofdealingwithdeadlocks:

1. Deadlockprevention

2. Deadlockdetection


DeadlockDetection

• Createthewaits-forgraph:

• Nodesaretransactions

• ThereisanedgefromTi à Tj ifTi iswaitingforTj toreleasealock

• Periodicallycheckfor(andbreak)cyclesinthewaits-forgraph


Summary

• ConcurrencyachievedbyinterleavingTXNssuchthatisolation&consistencyaremaintained

• Weformalizedanotionofserializability thatcapturedsucha“good”interleavingschedule

• Wedefinedconflictserializability,whichimpliesserializability

• Lockingallowsonlyconflictserializableschedules• Iftheschedulecompletes…(itmaydeadlock!)

Lecture8>Section2

Lectures 7 & 8: Transactions - web.stanford.eduweb.stanford.edu/class/cs145/lectures/lecture-8/Lecture_8_TXNs.pdfWhat you will learn about in this section 1. Our “model” of the

Documents