CS317 File and Database Systems -...

November 15, 2017 Sam Siewert

CS317File and Database Systems

Lecture 12, Part 2 – DBMS Transactions and ACID

http://dilbert.com/strips/comic/1992-01-21/

RemindersAssignment #5, Being Graded

Assignment #6, Physical DB Design, Team Assignments Posted

Assignment #6, DBMS Project of Your Interest– See Me during office hours as you need help– E-mail for help– Glad to show you EXEMPLAR Reports and Presentations

Exam #2 – Monday and Wednesday, Week 15

Assignment #6 Assessed with Final Grading along with Final Oral Exam (Presentation by Your Group)

Sam Siewert 2

Study for Exam #2EXAM #2 (12/5, 12/7)

Lecture-Week-8-1 through Lecture-Week-14-2Connolly and Begg Chapters 10-20 & 22Lecture-Week-15 Not Included (Final Quiz on Canvas)

Some Overlap with Exam #1 on Design Concepts and Strategy in Chapters 10 & 11

EXAM #1Lecture-Week-1-1 through Lecture-Week-6-2Connolly and Begg Chapters 1-11

Practice Quiz on Friday, 12/2

Sam Siewert 3

Interdisciplinary Nature of DBMS

Sam Siewert 4

DBMS

File Systems

Operating Systems

Programming Languages(SQL, OOP)

Security

Networking(Clusters, DR, Client/Server)

Storage(SAN, NAS, DAS)

Big

Data

Analytics

?

? ?

Visibility into DBMS / OS Interfacemysqladmin – External Tool to Interfaces to mysqldLow Concurrency, Large Total Threads and Locks

Sam Siewert 5

Run Benchmarks – E.g. Wisconsinmysqladmin --pass extended -i1

Operating EnvironmentOS+DBMS Provides MySQL Operating Environment

Interfaces with Scheduling [Process / Thread Execution]– Service – mysqld, Processing– Query Processing and Client Connections, Threads– Concurrency for Query Processing, Active Threads

Interfaces with File, Buffer and I/O Interfaces [Drivers]– ISAM [Indexed Sequential Access Method]– MySQL InnoDB maps through File System or Direct Partition– Memory Storage Engine - Memory Management– VM Paging and I/O Buffers in General

Transactions, Locks, Timestamps?

Sam Siewert 6

Example TransactionDo All SQL Commands or None

E.g. Add a New Branch Office and Assign a New Employee to It if Successful

Helps with Referential Integrity, but Also Race Conditions for Other Queries – E.g. We have a Branch Office with Nobody Working there? [Inconsistent Analysis]

Multiple SQL Commands are Wrapped Sam Siewert 7

Basic Operating System Synchronization Review

Binary Semaphores (Locks)

Readers + Writer(s) Problems

Critical Sections and MUTEX Semaphores

Counting Semaphores

Producer / Consumer Queues

Deadlock, Livelock (Starvation) – Dining Philosophers

Sam Siewert 8

Sam Siewert 9

Shared Mutually Exclusive Access Resource

Shared Memory Resources Require Protection from Interrupted / Preempted Writes and Read

E.g. Shared Memory State that Can’t Be Updated Atomically [e.g. a Structure, Array or “Record” – Like a Tuple]– Position[] = {x, y, z}

– To Update Position Requires More Than One Write Instruction

– What Happens on Interrupt Between Update of X and Y, Z?

– What if That Interrupt Releases a Service that Reads Position?

– Data Corruption!

– Same as DBMS Dirty Read [Uncommitted Dependency Problem]

Problems with Concurrent File UpdatesIssue with a RECORD Update in Memory – Dirty Read, Lost Update

Same Issues Exist with Concurrent File Access

See Beowulf File Writer/Read Example Code– Unsychronized –

http://mercury.pr.erau.edu/~siewerts/cs317/code/File-Transactions-Unsync/

– Synchronized -http://mercury.pr.erau.edu/~siewerts/cs317/code/File-Transactions-Sync/

Sam Siewert 10

Mutual Exclusion Critical SectionProtects Global Data for Multi-threaded Read/Write Access

http://www.ibm.com/developerworks/power/library/pa-soc5/

Non-Issue for Linux CFS (issue for POSIX FIFO policy) – “Against priority inheritance”, by Victor Yodaiken

With FAIR Scheduling in DBMS, We Don’t Have to Worry About Unbounded Priority Inversion, But Deadlock/Livelock, Yes

Luckily, Most DBMS are not ALSO Real-Time

Sam Siewert 11

Message QueuesProducer / Consumer Bounded Buffer is the Problem!Message Queues are the Answer

But, How do We Implement One??– We need mutual exclusion?– We need counting semaphores?

What is a Message Queue?– Atomic Operations for:

1. Enqueue2. Dequeue3. Tests and Notification for Is-Empty, Is-Full4. Blocks on Empty (or returns Empty Error EAGAIN)5. Blocks on Full (or returns Full Error EAGAIN)

Sam Siewert 12

POSIX Message Queue(Serialized Reads and Writes)

http://mercury.pr.erau.edu/~siewerts/extra/code/operating-systems/EXAMPLES/

mq_openmq_sendmq_receive

Name of Message Queue must be KNOWN globallyIt is a Global Bounded Buffer Where One Service Produces Message and Another ConsumesCan be Simplex or DuplexCan have Priority and Head of Queue Features

Sam Siewert 13

Sam Siewert 14

Blocking – In Unfair Scheduling

Blocking Indefinitely Can Be Viewed as Failure of a Service

Caused by Need for Shared Resource that is Unavailable Despite Availability of CPU Core

Ideally Eliminate Potential for Blocking During Service Execution, Or Use Timeouts!

If Elimination Impossible, Then We Want Bounded Blocking (Known Upper Bound on Blocking Time)

Sam Siewert 15

Resource Deadlock (Circular Wait)

A is holding X and would like YB is holding Y and would like XHow is this resolved?A and B could Block IndefinitelyEach could release X or Y and try again?– Can Result in Livelock– They Release, A grabs X, B grabs Y, Deadlock, Detection,

Release, A grabs X, B grabs Y …

Circular Wait Can Evolve over Complex Sets of Tasks and Resources (Hard to Detect or Prevent)Unbounded BlockingDetection Most Often with Watch-Dog and Sanity Monitors

A(X)

B(Y)Request Y

Request X

Deadlock NPTL Demo

Guaranteed Safe[root@localhost example-sync]# ./deadlock safeCreating thread 1Thread 1 spawnedTHREAD 1 grabbing resourcesTHREAD 1 got A, trying for BTHREAD 1 got A and BTHREAD 1 doneCreating thread 2Thread 2 spawnedrsrcACnt=1, rsrcBCnt=1will try to join CS threads unless they deadlockTHREAD 2 grabbing resourcesTHREAD 1 got B, trying for ATHREAD 2 got B and ATHREAD 2 doneAll done[root@localhost example-sync]#

Sam Siewert 16

Sam Siewert 17

Priority Inversion

Problem: Service Using Shared Resource May Suffer Unbounded Priority Inversion– Mutex Protection of a Resource May Result in Unbounded

Inversion– 3 Necessary Conditions for Unbounded Inversion

Three or More Services With Unique Priority in the System - High, Medium, Low Priority Sets of ServicesAt Least Two Services of Different Priority Share a Resource with Mutex Protection - One or More High and One or More Low Involved One or More Services Not Involved in the Mutex Has Priority Between the Two Involved in the Mutex

– What Happens?Low Priority Service Enters Mutex and High Priority Blocks on MutexThe Medium Priority Services Not Involved in the Mutex Can Interfere with the Low Priority Service for An Indeterminate Amount of Time

– Possible Solution: Priority Inheritance or Priority Ceiling

Priority Inversion NPTL Demo

First, 3 Threads with No CS[root@localhost example-sync]# ./pthread3ok 10000interference time = 10000 secsunsafe mutex will be createdPthread Policy is SCHED_OTHERPthread Policy is SCHED_OTHERmin prio = 1, max prio = 99PTHREAD SCOPE SYSTEMCreating thread 0Creating thread 1High prio 1 thread spawned at 1203339106 sec, 128498 nsecCreating thread 2Middle prio 2 thread spawned at 1203339106 sec, 128549 nsecCreating thread 3Low prio 3 thread spawned at 1203339106 sec, 128604 nsec**** 1 idle stopping at 1203339106 sec, 168299 nsec**** 2 idle stopping at 1203339106 sec, 172718 nsecStart services thread spawnedwill join service threads**** 3 idle stopping at 1203339106 sec, 188757 nsecLOW PRIO doneMID PRIO doneHIGH PRIO doneSTART SERVICE doneAll done[root@localhost example-sync]#

Sam Siewert 18

Priority Inversion NPTL Demo

3 Threads Prio H,L in CS and Prio M Not[root@localhost example-sync]# ./pthread3 10000interference time = 10000 secsunsafe mutex will be createdPthread Policy is SCHED_OTHERPthread Policy is SCHED_OTHERmin prio = 1, max prio = 99PTHREAD SCOPE SYSTEMCreating thread 0Creating thread 3Low prio 3 thread spawned at 1203339142 sec, 688239 nsecStart services thread spawnedwill join service threadsCreating thread 2Middle prio 2 thread spawned at 1203339143 sec, 688496 nsecCreating thread 1, CScnt=1High prio 1 thread spawned at 1203339143 sec, 688567 nsec**** 2 idle NO SEM stopping at 1203339143 sec, 726988 nsec**** 3 idle stopping at 1203339144 sec, 856797 nsecLOW PRIO doneMID PRIO done**** 1 idle stopping at 1203339146 sec, 968860 nsecHIGH PRIO doneSTART SERVICE doneAll done[root@localhost example-sync]#

Sam Siewert 19

Connection between OS and DBMSClient Connection is a Thread

Transactions are Threads, Scheduled by OS

Interleaving of Operations from Concurrent Transactions is Determined by the Operating System!

The I/O Schedule to Commit Updates in a Buffer to Storage are Determined by the DBMS

Sam Siewert 20

C&B REF - ACID – ATOMICITY, CONSISTENCY, ISOLATION, DURABILITY

TRANSACTION MANAGEMENT

Sam Siewert 21

Chapter 22 - ObjectivesFunction and importance of transactions

Properties of transactions

Concurrency Control– Meaning of serializability– How locking can ensure serializability– Deadlock and how it can be resolved– How timestamping can ensure serializability– Optimistic concurrency control– Granularity of locking – BIG LOCK [bad], E.g. Linux BKL

Scope of Locking Limited to C.S.Limited Scope means 1000’s of Locks!

Pearson Education © 2014 22

Chapter 22 - ObjectivesRecovery Control– Some causes of database failure.– Purpose of transaction log file.– Purpose of checkpointing.– How to recover following database failure.

Alternative models for long duration transactions.


ACID FeaturesA – Atomicity, means Non-interruptable Updates for Tuples and Logically Related Table Tuples [E.g. Delete/Promote an Employee and Re-assign Clients]

C – Consistency, means the DB state should not become inconsistent [E.g. Deleted Employee has Clients Still assigned to their Employee-ID foreign key]

I – Isolation so that Transactions Do Not Interfere with Another if Serialized [E.g. Roll-back of One Should Not Cascade into Roll-backs of Others]

Durability – Committed Transactions Should Be Stored to Persistent Storage and Not Lost! [Durable] Sam Siewert 24

Transaction SupportTransaction

Action, or series of actions, carried out by user orapplication, which reads or updates contents of database.

1. Logical unit of work on the database.

2. Application program is series of transactions with non-database processing in between.

3. Transforms database from one consistent state to another, although consistency may be violated during transaction.


Example Transactions


HR: Give Employee a Raise – Cost of Living

Mgt: Fire Employee and Reassign Client Properties

Transaction SupportCan have one of two outcomes:– Success - transaction commits and database reaches a

new consistent state.– Failure - transaction aborts, and database must be

restored to consistent state before it started.– Such a transaction is rolled back or undone.

Committed transaction cannot be aborted.

Aborted transaction that is rolled back can berestarted later.


State Transition Diagram for Transaction


Written to Storage(Cached w/o ATA Flush, SCSI FUA)

http://en.wikipedia.org/wiki/Disk_buffer

Completed TransactionBuffered for Write-back

Partially Completed TransactionCleared from Buffer – No Write-back

If We NEVER used CacheAnd ALWAYS used FUA, thishelps, But WAY TOO SLOW

Properties of TransactionsFour basic (ACID) properties that define a transactionare:

1. Atomicity ‘All or nothing’ property.

2. Consistency Must transform database from oneconsistent state to another.

3. Isolation Partial effects of incomplete transactionsshould not be visible to other transactions.

4. Durability Effects of a committed transaction arepermanent and must not be lost because of laterfailure.


DBMS Transaction Subsystem


Concurrency ControlProcess of managing simultaneous operations onthe database without having them interfere withone another.

1. Prevents interference when two or more users areaccessing database simultaneously and at leastone is updating data.

2. Although two transactions may be correct inthemselves, interleaving of operations mayproduce an incorrect result.


Need for Concurrency ControlThree examples of potential problems caused byconcurrency:

1. Lost update problem.

2. Uncommitted dependency problem.

3. Inconsistent analysis problem.


Lost Update ProblemSuccessfully completed update is overridden byanother user.

T1 withdrawing £10 from an account with balx,initially £100.

T2 depositing £100 into same account.

Serially, final balance would be £190.


Lost Update Problem

Loss of T2’s update avoided by preventing T1from reading balx until after update.T1 Stale ReadClassic Readers + Writers Problem


Should be 190!!

Uncommitted Dependency Problem [Dirty Read]

Occurs when one transaction can see intermediateresults of another transaction before it hascommitted.

T4 updates balx to £200 but it aborts, so balxshould be back at original value of £100.

T3 has read new value of balx (£200) and usesvalue as basis of £10 reduction, giving a newbalance of £190, instead of £90.


Uncommitted Dependency Problem

Problem avoided by preventing T3 from readingbalx until after T4 commits or aborts.


Should be 90!!

E.g. Insufficient Funds found in Source for Deposit, soMust Undo the Balance Update

Inconsistent Analysis ProblemOccurs when transaction reads several values but second transaction updates some of them during execution of first.

Sometimes referred to as dirty read or unrepeatable read.

T6 is totaling balances of account x (£100), account y (£50), and account z (£25).

Meantime, T5 has transferred £10 from balx to balz, so T6 now has wrong result (£10 too high).


Inconsistent Analysis Problem

Problem avoided by preventing T6 from readingbalx and balz until after T5 completed updates.Second Run of T6 Reveals Correct Sum, ButConfusing Pearson Education © 2014 38

Should be 175!!Lucky, but un-official read from cache before commit

SerializabilityObjective of a concurrency control protocol is toschedule transactions in such a way as to avoidany interference.

Could run transactions serially, but this limitsdegree of concurrency or parallelism in system.– E.g. All Transactions Enter One Giant Input Queue– Need to Know Start / End of Transactions [Like Messages

in Message Queue] – We will Try this!

Serializability identifies those executions oftransactions guaranteed to ensure consistency.


SerializabilitySchedule [An I/O or Update Schedule, Not OS Schedule]

Sequence of reads/writes by set of concurrent transactions.

Serial ScheduleSchedule where operations of each transaction areexecuted consecutively without any interleaved operationsfrom other transactions.

• No guarantee that results of all serial executions ofa given set of transactions will be identical.


Scoping a Transaction – START to COMMIT

E.g. DML for Removal of Employee and Update of Related Tables and Tuples the Refer to Employee

Book - BEGIN TRANSACTION, COMMIT, ROLLBACK

MySQL Transactions [Scoped, Not Time Ordered]1. START TRANSACTION2. DML Updates [Delete Incompetent Employee, Re-assign

Properties, Oops, Employee is Owner’s Son, Rollback, Just Re-assign Properties In New Transaction]

3. ROLLBACK if ERRORS during DML Updates4. COMMIT assuming no ERRORS during DML updates

Sam Siewert 41

Nonserial ScheduleSchedule where operations from set of concurrenttransactions are interleaved.

Objective of serializability is to find nonserialschedules that allow transactions to execute concurrently without interfering with one another.

In other words, want to find nonserial schedulesthat are equivalent to some serial schedule. Such aschedule is called serializable.


SerializabilityIn serializability, ordering of read/writes is important:(a) If two transactions only read a data item, they do not

conflict and order is not important.

(b) If two transactions either read or write separate dataitems, they do not conflict and order is not important.

(c) If one transaction writes a data item and another readsor writes same data item (or a portion of it!), order ofexecution is important.


Example of Conflict Serializability


Schedule S1 Schedule S2 Schedule S3 - Serialized

S1 = S2 = S3 in Terms of Final DB State, So Consistent

SerializabilityConflict serializable schedule orders any conflicting operations in same way as some serial execution.

Under constrained write rule (transaction updates data item based on its old value, which is first read), use precedence graph to test for serializability.


Precedence GraphCreate:– node for each transaction;– a directed edge Ti Tj, if Tj reads the value of an item

written by TI;– a directed edge Ti Tj, if Tj writes a value into an item

after it has been read by Ti.

If precedence graph contains cycle schedule is notconflict serializable.


Example - Non-conflict serializableschedule

T9 is transferring £100 from one account withbalance balx to another account with balance baly.

T10 is increasing balance of these two accounts by10%.

Precedence graph has a cycle and so is not serializable.


Example - Non-conflict serializableschedule

Pearson Education © 2014 48Figure 22.8

T10 before T9 Not EquivalentT9 before T10 Not EquivalentInterleaved is Not Equivalent toAny Serialized ScheduleNow what???

Say X=1000, Y=1000T10 before T9, X=1200, Y=1000T9 before T10, X=1210, Y=990Interleaved, X=1210, Y=1000

View SerializabilityOffers less stringent definition of schedule equivalence than conflict serializability.

Two schedules S1 and S2 are view equivalent if:1. For each data item x, if Ti reads initial value

of x in S1, Ti must also read initial value of xin S2.

2. For each read on x by Ti in S1, if value readby Ti is written by Tj, Ti must also readvalue of x produced by Tj in S2.

3. For each data item x, if last write on xperformed by Ti in S1, same transactionmust perform final write on x in S2.


View Serializability

Schedule is view serializable if it is view equivalentto a serial schedule.

Every conflict serializable schedule is view serializable, although converse is not true.

It can be shown that any view serializable schedulethat is not conflict serializable contains one ormore blind writes.

In general, testing whether schedule is serializableis NP-complete. - IMPRACTICAL


Quick Review of P, NP, NP-CompletePolynomial bound is composed of addition/subtraction, multiplication and non-negative integer exponentsNP Complete – Not P, but Verify in P

Sam Siewert 51

O(C) = constantO(log(n)) = log [binary search]O(n) = linearO(nlog(n)) = loglinear [heapsort]O(n2) = nested loop [bubble sort]O(nC) = nested loops [matching]O(Cn) = exponential [brute force search]O(n!) = factorial [all permutations]

NP Problems

P Problems

NP Complete

Example - View Serializable schedule


Blind Write Blind Write

No, impacts read

Ok, after T11, before T13

T13 is the Final Write and State of The DB [Blind Write]T12 Conflicts with T11 and must be Moved Before or After (Serialized)Only Consistent Serialized State is to Move it Between T11 and T13

Serialization into Transaction Queue?Does Not Work - No Practical Way to Order for Consistency– Conflict Serialization is Not Always Possible with Consistency, so

Violates ACID– View Serialization is NP-Hard, So Impractical to Implement– We Know Start and End of Transaction, but Not When it Was

Received [No Timestamp, Not in Single Receive FIFO]

What are the Other Options?

Locking Critical Sections in Transactions Just Like an OS

Timestamp Ordering – Serialize in Order Received, Creates a Transaction Time Ordered Queue (Global FIFO)

Sam Siewert 53

RecoverabilitySerializability identifies schedules that maintain database consistency, assuming no transaction fails.

Could also examine recoverability of transactionswithin schedule.

If transaction fails, atomicity requires effects oftransaction to be undone.

Durability states that once transaction commits, itschanges cannot be undone (without runninganother, compensating, transaction).


Recoverable ScheduleA schedule where, for each pair of transactions Tiand Tj, if Tj reads a data item previously written byTi, then the commit operation of Ti precedes thecommit operation of Tj.


Concurrency Control TechniquesTwo basic concurrency control techniques:– Locking,– Timestamping.

Both are conservative approaches: delay transactions in case they conflict with other transactions.

Optimistic methods assume conflict is rare andonly check for conflicts at commit.


LockingTransaction uses locks to deny access to othertransactions and so prevent incorrect updates.

1. Most widely used approach to ensure serializability. [E.g. OS, File Systems, Bus]

2. Generally, a transaction must claim a shared (read)or exclusive (write) lock on a data item before reador write.

3. Lock prevents another transaction from modifyingitem or even reading it, in the case of a write lock.


Locking - Basic Rules1. If transaction has shared lock on item, can read but not

update item.

2. If transaction has exclusive lock on item, can both read andupdate item.

3. Reads cannot conflict, so more than one transaction can hold shared locks simultaneously on same item.

4. Exclusive lock gives transaction exclusive access to thatitem.

• Some systems allow transaction to upgrade read lock to anexclusive lock, or downgrade exclusive lock to a shared lock.


Example - Incorrect Locking Schedule

For two transactions on slide 45 (figure 22.8), a valid scheduleusing basic rules is:

S = {write_lock(T9, balx), read(T9, balx), write(T9, balx),

unlock(T9, balx), write_lock(T10, balx), read(T10, balx), write(T10, balx),

unlock(T10, balx), write_lock(T10, baly), read(T10, baly), write(T10, baly),

unlock(T10, baly), commit(T10), write_lock(T9, baly), read(T9, baly), write(T9, baly),

unlock(T9, baly), commit(T9)

}



If at start, balx = 100, baly = 400, result should be:

– balx = 220, baly = 330, if T9 executes before T10, or– balx = 210, baly = 340, if T10 executes before T9.

However, result gives balx = 220 & baly = 340.

Commit Order is T9 and T10 Still Interleave

S is not a serializable schedule.



Problem is that transactions release locks too soon, resulting in loss of total isolation and atomicity.

To guarantee serializability, need an additional protocol concerning the positioning of lock and unlock operations in every transaction.


Two-Phase Locking (2PL)Transaction follows 2PL protocol if all lockingoperations precede first unlock operation in thetransaction.

Two phases for transaction:– Growing phase - acquires all locks but cannot release

any locks.

– Shrinking phase - releases locks but cannot acquire anynew locks.


Prevent Lost Update using 2PL


BoundedBlocking

Preventing Uncommitted Dependency Problem using 2PL


Prevent Inconsistent Analysis with 2PL


Cascading RollbackIf every transaction in a schedule follows 2PL,schedule is serializable.

However, problems can occur with interpretationof when locks can be released.


Cascading Rollback


Cascading RollbackTransactions conform to 2PL.

T14 aborts.

Since T15 is dependent on T14, T15 must also berolled back. Since T16 is dependent on T15, it toomust be rolled back.

This is called cascading rollback.

To prevent this with 2PL, leave release of all locksuntil end of transaction.


Concurrency Control with Index Structures

Could treat each page of index as a data item and apply2PL.

However, as indexes will be frequently accessed,particularly higher levels, this may lead to high lockcontention.

Two points about index traversal:– Search path starts from root and moves down to leaf

nodes but search never moves back up tree. Thus,once a lower-level node has been accessed, higher-level nodes in that path will not be used again.

– When new index value (key and pointer) is beinginserted into a leaf node, then if node is not full,insertion will not cause changes to higher-levelnodes.


Concurrency Control with Index Structures

Only have to exclusively lock leaf node in such a case,and only exclusively lock higher-level nodes if node isfull and has to be split.

Thus, can derive following locking strategy:– For searches, obtain shared locks on nodes starting at

root and proceeding downwards along required path.Release lock on node once lock has been obtained on thechild node.

– For insertions, conservative approach would be to obtainexclusive locks on all nodes as we descend tree to the leafnode to be modified.

– For more optimistic approach, obtain shared locks on allnodes as we descend to leaf node to be modified, whereobtain exclusive lock. If leaf node has to split, upgradeshared lock on parent to exclusive lock. If this node alsohas to split, continue to upgrade locks at next higher level.


Deadlock – Circular WaitAn impasse that may result when two (or more)transactions are each waiting for locks held by theother to be released.


T17 holds X, wants Y ; T18 holds Y, wants X; -- Circular Wait

DeadlockOnly one way to break deadlock: abort one ormore of the transactions.

Deadlock should be transparent to user, so DBMSshould restart transaction(s).

However, in practice DBMS cannot restart abortedtransaction since it is unaware of transaction logiceven if it was aware of the transaction history(unless there is no user input in the transaction orthe input is not a function of the database state).


DeadlockThree general techniques for handling deadlock:– Timeouts.– Deadlock prevention.– Deadlock detection and recovery.


TimeoutsTransaction that requests lock will only wait for asystem-defined period of time.

If lock has not been granted within this period, lockrequest times out.

In this case, DBMS assumes transaction may bedeadlocked, even though it may not be, and it abortsand automatically restarts the transaction.


Deadlock PreventionDBMS looks ahead to see if transaction would causedeadlock and never allows deadlock to occur.

Could order transactions using transaction timestamps:– Wait-Die - only an older transaction can wait for younger

one, otherwise transaction is aborted (dies) and restartedwith same timestamp.

– Wound-Wait - only a younger transaction can wait for anolder one. If older transaction requests lock held byyounger one, younger one is aborted (wounded).


Deadlock Detection and RecoveryDBMS allows deadlock to occur but recognizes itand breaks it.

Usually handled by construction of wait-for graph(WFG) showing transaction dependencies:– Create a node for each transaction.– Create edge Ti -> Tj, if Ti waiting to lock item

locked by Tj.

Deadlock exists if and only if WFG contains cycle.

WFG is created at regular intervals.Pearson Education © 2014 76

Example - Wait-For-Graph (WFG)


Recovery from Deadlock Detection

Several issues:– choice of deadlock victim;– how far to roll a transaction back;– avoiding starvation [Unfortunate

Synchronization of Acquire, Wait,Timeout, Release, Try Again]

– Random Back-off Can Be Used toAvoid Starvation


TimestampingTransactions ordered globally so that older transactions, transactions with smaller timestamps, get priority in the event of conflict.

Conflict is resolved by rolling back and restartingtransaction.

No locks so no deadlock.


TimestampingTimestamp

A unique identifier created by DBMS that indicatesrelative starting time of a transaction.

Can be generated by using system clock at timetransaction started, or by incrementing a logicalcounter every time a new transaction starts.


TimestampingRead/write proceeds only if last update on that dataitem was carried out by an older transaction.Otherwise, transaction requesting read/write isrestarted and given a new timestamp.Also timestamps for data items:– read-timestamp - timestamp of last transaction to read

item;– write-timestamp - timestamp of last transaction to write

item.


Timestamping - Read(x)Consider a transaction T with timestamp ts(T):

ts(T) < write_timestamp(x)– x already updated by younger (later) transaction.– Transaction must be aborted and restarted with a new

timestamp.ts(T) < read_timestamp(x)

– x already read by younger transaction.– Roll back transaction and restart it using a later timestamp.


Timestamping - Write(x)ts(T) < write_timestamp(x)

– x already written by younger transaction.– Write can safely be ignored - ignore obsolete write rule.

Otherwise, operation is accepted and executed.


Example – Basic Timestamp Ordering


Comparison of Methods


Orders conflicting operationsAs “some” serial schedule

Including those with data corruptionAnd inconsistent DB states

Less Restrictive Operation OrderingAs “some” serial schedule[Impractical – NP-Complete]

Time-stamp ordering(practical solution)

Growing phase – acquire locksShrinking phase – release locks

VS = View SerializationCS = Conflict SerializationTS = Time Stamp Serialization2PL = 2 Phase Locking

SummaryConcurrency due to Multiple Clients and Transactions Mapped to OS Threads [Readers, Writers]

Causes Problems with Split Transactions– Lost Update– Dirty Read or Uncommitted Dependency– Fuzzy Read, Phantom Read

Serialization Using Locks – Not Sufficient for Consistency if Lock Scope Too Small and Can Cause Deadlock!Recoverability – Atomicity Requirement2PL – Growing and Shrinking Phase – Helps with Lock Scope, but Still have Deadlock/LivelockCascading Roll-back and Rigorous/Strict 2PLDeadlock Problem – Prevention, Detect & BreakAlternative Timestamp Methods

Rigorous/Strict 2PL with Deadlock Prevention or Detect & Break or Timestamp is Best

Sam Siewert 86

CS317 File and Database Systems -...

Documents

Transcript of CS317 File and Database Systems -...