Spring 2017 TRANSACTION MANAGEMENTpages.cs.wisc.edu/~jignesh/cs564/notes/lec14-xact.pdfTransaction...

TRANSACTIONMANAGEMENT[CH 16]

Spring2017

4/25/17 CS 564: Database Management Systems; (c) Jignesh M. Patel, 2013 1

4/25/17 CS 564: Database Management Systems 2

TransactionManagementBank Balance : $100

Sufficient funds?

New balance: $75

Bank Balance : $75!

Read Balance: $100You

Pay $25Yes

Read (A);Check (A > $25);Pay ($25);A = A – 25;Write (A);


TransactionManagement

• Inconsistency– Interleavingactionsofdifferentuserprograms– Systemcrash/userabort/…

• Providetheusersanillusionofasingle-usersystem– Couldinsistonadmittingonlyonequeryintothesystematanytime

• lowerutilization:CPU/IOoverlap• longrunningqueriesstarveotherqueries

Bank Balance : $100

Sufficient funds?Sufficient funds?

New balance: $75New balance: $75

Bank Balance : $75!

Read Balance: $100 Read Balance: $100You Your Significant Other

Pay $25Yes

Pay $25Yes

Read (A);Check (A > $25);Pay ($25);A = A – 25;Write (A);


WhatisaTransaction?• Collectionofoperationsthatformasinglelogicalunit

– Asequenceofmanyactionsconsideredtobeoneatomicunitofwork

• Logicalunit:– begintransaction….(SQL)endtransaction

• Operations:– Read(X),Write(X):AssumeR/Wontuples(canberelaxed)– Specialactions:begin,commit,abort

• DesirableProperty:MustleavetheDBinaconsistentstate– (DBisconsistentwhenthetransactionbegins)– Consistency:DBMSonlyenforcesICsspecifiedbytheuser– DBMSdoesnotunderstandanyothersemanticsofthedata


TheACID Properties

User

TMXact. Mgmt.(logging)

RMRecovery Mgmt.(WAL, …)

CCConcurrency Ctrl.(locking)

BeginRead (A);A = A – 25;Write (A);Read (B);B = B + 25;Write (B);

Commit

• Atomicity:AllactionsintheXacthappen,ornonehappen.

• Consistency:ConsistentDB+consistentXact⇒ consistentDB

• Isolation:ExecutionofoneXact isisolatedfromthatofotherXacts.

• Durability:IfaXact commits,itseffectspersist.


Schedules• Schedule:AninterleavingofactionsfromasetofXacts,wheretheactionsofanyoneXact areintheoriginalorder.– ActionsofXacts asseenbytheDB– Completeschedule:eachXact endsincommitorabort

– Serialschedule:NointerleavingofactionsfromdifferentXacts.

• InitialState+Schedule® FinalState

T1 T2beginR(A)W(A)

beginR(B)W(B)

R(C)W(C)

commitabort

Time


AcceptableSchedules• Onesensible“isolated,consistent”schedule:

– RunXacts oneatatime(serialschedule)

• Serializable schedules:– Finalstateiswhatsome complete serialscheduleofcommitted transactionswouldhaveproduced.

– Candifferentserialscheduleshavedifferentfinalstates?• Yes,allare“OK”!

– AbortedXacts?• ignorethemforalittlewhile(madeto‘disappear’usinglogging)

– Otherexternalactions(besidesR/WtoDB)• e.g.printacomputedvalue,fireamissile,…• Assume(forthisclass)thesevaluesarewrittentotheDB,andcanbeundone


SerializabilityViolations• @Start(A,B)=(1000,100)

– End(990,210)

• T1→T2:– (900,200)→(990,220)

• T2→T1:– (1100,110)→(1000,210)

T1: Transfer $100 from A to B

T2: Add 10% interest to A & B

beginbegin

R(A) /A -= 100W(A)

R(A) /A *= 1.1W(A)R(B) /B *= 1.1W(B)commit

R(B) /B += 100W(B)commit

n W-R conflict: Dirty readn Could lead to a non-

serializable executionn Also R-W and W-W conflicts

Database Inconsistent


MoreConflicts• RWConflicts(UnrepeatableRead)

– RT2(X)→WT1(X), T1overwriteswhatT2read.– RT2(X)→WT1(X)→RT2(X).T2seesadifferentXvalue!

• WWConflicts(OverwritingUncommited Data)– T2overwriteswhatT1wrote.

• E.g.:Studentsinthesamegroupgetthesameprojectgrade.• TP:W (X=A),W (Y=A) TTA:W (X=B),W (Y=B)• WP(X=A) →WTA(X=B) →WTA(Y=B) →WP(Y=A)[Note:noreads]

– Usuallyoccursinconjunctionwithotheranomalies.• Unlessyouhave“blindwrites”.


Now,AbortedTransactions• Serializable schedule:Equivalenttoaserialscheduleofcommitted Xacts.– asifabortedXacts neverhappened.

• TwoIssues:– HowdoesoneundotheeffectsofaXact?

• We’llcoverthisinlogging/recovery– WhatifanotherXact seestheseeffects??

• MustundothatXact aswell!


CascadingAborts• AbortofT1requiresabortofT2!

– CascadingAbort

T1 T2beginR(A)W(A)

beginR(A)W(A)

abort commitabort


CascadingAborts• AbortofT1requiresabortofT2!

– CascadingAbort

T1 T2beginR(A)W(A)

beginR(A)W(A)

abort

n Consider commit of T2n Can we undo T2?

n Recoverable schedule: Commit only after all xacts that supply dirty data have committed.

commitabortcommit

commit


CascadingAborts T1 T2beginR(A)W(A)

beginR(A)W(A)

abort commitabortcommit

commit

n ACA (avoids cascading abort) schedule n Transaction only reads committed datan One in which cascading abort cannot arise.n Schedule is also recoverable

abort

Commit

W(A)

commit

begin

R(A)

begin

W(A)

R(A)

T2T1


Locking:ATechniqueforC.C.• Concurrencycontrolusuallydonevialocking.• Lockinfomaintainedbya“lockmanager”:

– Stores(XID,RID,Mode)triples.• Thisisasimplisticview;sufficesfornow.

– ModeÎ {S,X}– Lockcompatibilitytable:

-- S X

--S

X

√

√

√

√ √

√n If a Xact can’t get a lock

n Suspended on a wait queuen When are locks acquired?

n Buffer manager call!


Two-PhaseLocking(2PL)• 2PL:

– IfTwantstoread(modify)anobject,firstobtainsanS(X)lock

– IfTreleasesanylock,itcanacquirenonewlocks!– Gurantees serializability!Why?

n Strict 2PL:n Hold all locks until end of Xactn Guarantees serializability, and ACA

too!n Note ACA schedules are always

recoverable Time#

lock

s

growing phase Shrinkingphase

lock point


T1 T2

beginbegin

X(A)R(A)W(A)

SchedulewithLocksT1 T2

beginbegin

X(A)R(A)W(A)

X(A) – Wait!X(B)R(B)W(B)Ux(A), Ux(B)/commit

R(A)W(A)…



beginbegin

R(A) /A -= 100W(A)




Deadlocks

• Deadlockscancausethesystemtowaitforever.

• Needtodetectdeadlockandbreak,orpreventdeadlocks

• Simplemechanism:timeoutandabort

• Moresophisticatedmethodsexist

XT1(B), XT2(A), ST1(A), ST2(B)T1 T2

A

B


PrecedenceGraphT1: Xfer.

$100 from A to B

T2: Add 10%

interestbegin

beginR(A)W(A)

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

R(B)W(B)commit

• Precedence (orSerializability)graph:– Nodes=CommittedXacts– Conflicts=Arcs T1 T2

n Conflict equivalent:n Same sets of actionsn Conflicting actions in the same order

n Conflict serializable: Conflict equivalent to a serial schedule


SchedulewithLocksT1 T2

beginbegin

X(A)R(A)W(A)

X(A) – Wait!X(B)R(B)W(B)Ux(A), Ux(B)/commit

R(A)W(A)…



beginbegin

R(A) /A -= 100W(A)



T1 T2T1 T2


ConflictSerializability&Graphs

• WhyStrict2PL?– GuaranteesACA

• readonlycommittedvalues– How? WritelocksuntilEOT

• NoWWorWR=>onabortreplaceoriginalvalue

Theorem: A schedule is conflict serializable iff its precedence graph is acyclicTheorem: 2PL ensures that the precedence graph will be acyclic


Deadlocks

• Deadlockscancausethesystemtowaitforever.• Needtodetectdeadlockandbreak,orpreventdeadlocks• Detectdeadlock

– Drawalockgraph.Cyclesimpliesadeadlock• Alternativewaysofdealingwithdeadlock

– BreakDeadlock• Oneachlockrequest“updatethelockgraph”.Ifacycleisdetected,abortoneofthetransactions.Theabortedtransactionisrestartedafterwaitingforatime-outinterval.

– Preventdeadlock• Assignprioritiestothetransactions.Ifatransaction,T1,requestsalockthatisbeingheldbyanothertransaction,T2,withalowerpriority,thenT1“snatches”thelockfromT2byabortingT2(whichfreesupthelockontheresource).T2isthenrestartedagainafteratime-out.

XT1(B), XT2(A), ST1(A), ST2(B)T1 T2

A

B


TransactionSupportinSQL• Transactionboundary

– Beginimplicitly,orendbyCommitwork,Rollbackwork– Forlongrunningtransactions:Savepoint

• Transactioncharacteristics– Diagnosticsize:#errormessages…– Accessmode:Readonly,ReadWrite– Isolationlevel

• Serializable:default• Repeatablereads:

– Readonlycommittedrecords– BetweentworeadsbythesameXact,noupdatesbyanotherXact

• Readcommitted– Readonlycommittedrecords

• Readuncommitted

(long-term R/W locks on phantoms too)(long-term R/W locks on real objects)

(long-term W locks/short-term R locks)

(Read only, no R locks!)

(not in the official course syllabus)


PhantomProblem• T1:ScanSailorsfortheoldestsailorforratings1and2

– Assumethatatthestarttheoldestsailorwithrating1hasage80,oldestsailorwithrating2hasage90,andthesecondoldestsailorwithrating2is85yearsold

– T1identifiespageswithsailorshavingarating1,andlocksthesepages.Itcomputesthefirsttuple(rating=1,oldest-age=80)

– T1thengetsreadytolockpageswithsailortupleswithrating2.However,beforeitcangetstarted,T2arrives

• T2:Insertsatuplewithrating1andage99,anddeletestheoldestsailorwithrating2(whoseageis90)

– Thenewtupleisinsertedintoapagethatdoesn’thaveasailorwithrating1or2,andisnotlockedbyT1

– T2commits• T1nowresumesandcompleteslookingatsailorswithrating2.• ThefinalanswerproducedbyT1is(1,80)(2,85)doesnotcorrespondtoeitherofthe

twoserialschedules:– T1->T2 Answer:(1,80),(2,90)– T2->T1 Answer:(1,99),(2,85)



TransactionandConstraints

• Solution:– Inserttuplesinthesametransaction– Defertheconstraintchecking

• SQLconstraintmodes– DEFERRED:Checkatcommittime.– IMMEDIATE:Checkimmediately

Create Table A (akey, bref, …)

Create Table B (bkey, aref, …)Q: How to insert the firsttuple, either in A or B?



n Atomicity: All actions in the Xact happen, or none happen.

n Consistency: Consistent DB + consistent Xact ⇒ consistent DB

n Isolation: Execution of one Xact is isolated from that of other Xacts.

n Durability: If a Xact commits, its effects persist.

TheACID Properties

User

TMXact. Mgmt.(logging)

RMRecovery Mgmt.(WAL, …)

CCConcurrency Ctrl.(locking)

Spring 2017 TRANSACTION MANAGEMENTpages.cs.wisc.edu/~jignesh/cs564/notes/lec14-xact.pdfTransaction...

Documents

Transcript of Spring 2017 TRANSACTION MANAGEMENTpages.cs.wisc.edu/~jignesh/cs564/notes/lec14-xact.pdfTransaction...