chapter 22 · 2019-12-06 · deadlock. only one way to break deadlock: abort one or more of the...

Chapter 22

Transaction Management

Pearson Education © 2014

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.

Pearson Education © 2014 2

Chapter 22 - Objectives

Recovery ControlSome causes of database failure.Purpose of transaction log file.Purpose of checkpointing.How to recover following database failure.

Alternative models for long durationtransactions.

Pearson Education © 2014 3

Transaction SupportTransaction

Action, or series of actions, carried out by useror application, which reads or updates contentsof database.

• Logical unit of work on the database.• Application program is series of transactions with

non-database processing in between.• Transforms database from one consistent state to

another, although consistency may be violatedduring transaction.

Pearson Education © 2014 4

Example Transaction

Pearson Education © 2014 5

Transaction Support

Can have one of two outcomes:Success - transaction commits and databasereaches a new consistent state.Failure - transaction aborts, and database mustbe 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 canbe restarted later.

Pearson Education © 2014 6

State Transition Diagram for Transaction

Pearson Education © 2014 7

Properties of Transactions

Four basic (ACID) properties that define atransaction are:

Atomicity ‘All or nothing’ property.Consistency Must transform database from oneconsistent state to another.Isolation Partial effects of incomplete transactionsshould not be visible to other transactions.Durability Effects of a committed transaction arepermanent and must not be lost because of laterfailure.

Pearson Education © 2014 8

DBMS Transaction Subsystem

Pearson Education © 2014 9

Concurrency ControlProcess of managing simultaneousoperations on the database without havingthem interfere with one another.

• Prevents interference when two or moreusers are accessing database simultaneouslyand at least one is updating data.

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

Pearson Education © 2014 10

Need for Concurrency Control

Three examples of potential problemscaused by concurrency:

Lost update problem.Uncommitted dependency problem.Inconsistent analysis problem.

Pearson Education © 2014 11

Lost Update Problem

Successfully completed update is overriddenby another user.T1 withdrawing £10 from an account withbalx, initially £100.T2 depositing £100 into same account.Serially, final balance would be £190.

Pearson Education © 2014 12

Lost Update Problem

Loss of T2’s update avoided by preventingT1 from reading balx until after update.

Pearson Education © 2014 13

Uncommitted Dependency Problem

Occurs when one transaction can seeintermediate results of another transactionbefore it has committed.Referred to as a dirty readT4 updates balx to £200 but it aborts, so balxshould be back at original value of £100.T3 has read new value of balx (£200) anduses value as basis of £10 reduction, giving anew balance of £190, instead of £90.

Pearson Education © 2014 14

Uncommitted Dependency Problem

Problem avoided by preventing T3 fromreading balx until after T4 commits oraborts.

Pearson Education © 2014 15

Inconsistent Analysis Problem

Occurs when transaction reads severalvalues but second transaction updates someof them during execution of first.T6 is totaling balances of account x (£100),account y (£50), and account z (£25).Meantime, T5 has transferred £10 from balxto balz, so T6 now has wrong result (£10 toohigh).

Pearson Education © 2014 16

Inconsistent Analysis Problem

Problem avoided by preventing T6 fromreading balx and balz until after T5completed updates.

Pearson Education © 2014 17

Serializability

Objective of a concurrency control protocolis to schedule transactions in such a way asto avoid any interference.Could run transactions serially, but thislimits degree of concurrency or parallelismin system.Serializability identifies those executions oftransactions guaranteed to ensureconsistency.

Pearson Education © 2014 18

SerializabilitySchedule

Sequence of reads/writes by set of concurrenttransactions.

Serial ScheduleSchedule where operations of each transactionare executed consecutively without anyinterleaved operations from other transactions.

• No guarantee that results of all serialexecutions of a given set of transactions willbe identical.

Pearson Education © 2014 19

Nonserial Schedule

Schedule where operations from set ofconcurrent transactions are interleaved.

Objective of serializability is to find nonserialschedules that allow transactions to executeconcurrently without interfering with oneanother.

In other words, want to find nonserialschedules that are equivalent to some serialschedule. Such a schedule is calledserializable.

Pearson Education © 2014 20

Serializability

In serializability, ordering of read/writes isimportant:(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 data items, they do not conflict andorder is not important.

(c) If one transaction writes a data item andanother reads or writes same data item, orderof execution is important.

Pearson Education © 2014 21

Example of Conflict Serializability

Pearson Education © 2014 22

Schedule 1 Schedule 2 Schedule 3

Serializability

Conflict serializable schedule orders anyconflicting operations in same way as someserial execution.Under constrained write rule (transactionupdates data item based on its old value,which is first read), use precedence graph totest for serializability.

Pearson Education © 2014 23

Precedence Graph

Create:node for each transaction;a directed edge Ti → Tj, if Tj reads the value ofan item written by TI;a directed edge Ti → Tj, if Tj writes a value intoan item after it has been read by Ti.a directed edge Ti → Tj, if Tj writes a value intoan item after it has been written by Ti.

If precedence graph contains cycle scheduleis not conflict serializable.

Pearson Education © 2014 24

Example - Non-conflict serializable schedule

T9 is transferring £100 from one account withbalance balx to another account withbalance baly.T10 is increasing balance of these twoaccounts by 10%.Precedence graph has a cycle and so is notserializable.

Pearson Education © 2014 25

Example – Not (conflict serializable schedule)

Pearson Education © 2014 26

Recoverability

Serializability identifies schedules thatmaintain database consistency, assuming notransaction fails.Could also examine recoverability oftransactions within schedule.If transaction fails, atomicity requires effectsof transaction to be undone.Durability states that once transactioncommits, its changes cannot be undone(without running another, compensating,transaction).

Pearson Education © 2014 27

Recoverable Schedule

A schedule where, for each pair oftransactions Ti and Tj, if Tj reads a data itempreviously written by Ti, then the commitoperation of Ti precedes the commitoperation of Tj.

Pearson Education © 2014 28

Concurrency Control Techniques

Two basic concurrency control techniques:Locking,Timestamping.

Both are conservative approaches: delaytransactions in case they conflict with othertransactions.Optimistic methods assume conflict is rareand only check for conflicts at commit.

Pearson Education © 2014 29

LockingTransaction uses locks to deny access to othertransactions and so prevent incorrectupdates.

• Most widely used approach to ensureserializability.

• Generally, a transaction must claim a shared(read) or exclusive (write) lock on a data itembefore read or write.

• Lock prevents another transaction frommodifying item or even reading it, in the caseof a write lock.

Pearson Education © 2014 30

Locking - Basic Rules

If transaction has shared lock on item, canread but not update item.If transaction has exclusive lock on item, canboth read and update item.Reads cannot conflict, so more than onetransaction can hold shared lockssimultaneously on same item.Exclusive lock gives transaction exclusiveaccess to that item.

Pearson Education © 2014 31

Locking - Basic Rules

Some systems allow transaction to upgraderead lock to an exclusive lock, or downgradeexclusive lock to a shared lock.

Pearson Education © 2014 32

Example - Incorrect Locking Schedule

For two transactions above, a valid scheduleusing these 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) }

Pearson Education © 2014 33

Example - Incorrect Locking Schedule

If at start, balx = 100, baly = 400, result shouldbe:

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

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

S is not a serializable schedule.

Pearson Education © 2014 34

Example - Incorrect Locking Schedule

Problem is that transactions release lockstoo soon, resulting in loss of total isolationand atomicity.To guarantee serializability, need anadditional protocol concerning thepositioning of lock and unlock operations inevery transaction.

Pearson Education © 2014 35

Two-Phase Locking (2PL)

Transaction follows 2PL protocol if alllocking operations precede first unlockoperation in the transaction.

Two phases for transaction:Growing phase - acquires all locks but cannotrelease any locks.Shrinking phase - releases locks but cannotacquire any new locks.

Pearson Education © 2014 36

Preventing Lost Update Problem using 2PL

Pearson Education © 2014 37

Preventing Uncommitted Dependency Problemusing 2PL

Pearson Education © 2014 38

Preventing Inconsistent Analysis Problem using 2PL

Pearson Education © 2014 39

Cascading Rollback

If every transaction in a schedule follows2PL, schedule is serializable.However, problems can occur withinterpretation of when locks can bereleased.

Pearson Education © 2014 40

Cascading Rollback

Pearson Education © 2014 41

Cascading Rollback

Transactions conform to 2PL.T14 aborts.Since T15 is dependent on T14, T15 must alsobe rolled back. Since T16 is dependent on T15,it too must be rolled back.This is called cascading rollback.To prevent this with 2PL, leave release of alllocks until end of transaction.

Pearson Education © 2014 42

Deadlock

An impasse that may result when two (ormore) transactions are each waiting for locksheld by the other to be released.

Pearson Education © 2014 43

Deadlock

Only one way to break deadlock: abort oneor more of the transactions.Deadlock should be transparent to user, soDBMS should restart transaction(s).However, in practice DBMS cannot restartaborted transaction since it is unaware oftransaction logic even if it was aware of thetransaction history (unless there is no userinput in the transaction or the input is not afunction of the database state).

Pearson Education © 2014 44

Deadlock

Three general techniques for handlingdeadlock:

Timeouts.Deadlock prevention.Deadlock detection and recovery.

Pearson Education © 2014 45

Timeouts

Transaction that requests lock will only waitfor a system-defined period of time.If lock has not been granted within thisperiod, lock request times out.In this case, DBMS assumes transaction maybe deadlocked, even though it may not be,and it aborts and automatically restarts thetransaction.

Pearson Education © 2014 46

Deadlock Prevention

DBMS looks ahead to see if transaction wouldcause deadlock and never allows deadlock tooccur.Could order transactions using transactiontimestamps:

Wait-Die - only an older transaction can wait foryounger one, otherwise transaction is aborted(dies) and restarted with same timestamp.Wound-Wait - only a younger transaction canwait for an older one. If older transactionrequests lock held by younger one, younger oneis aborted (wounded).

Pearson Education © 2014 47

Deadlock Detection and Recovery

DBMS allows deadlock to occur butrecognizes it and breaks it.Usually handled by construction of wait-forgraph (WFG) showing transactiondependencies:

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 containscycle.WFG is created at regular intervals.

Pearson Education © 2014 48

Example - Wait-For-Graph (WFG)

Pearson Education © 2014 49

Recovery from Deadlock Detection

Several issues:choice of deadlock victim;how far to roll a transaction back;

avoiding starvation.

Pearson Education © 2014 50

Timestamping

Transactions ordered globally so that oldertransactions, transactions with smallertimestamps, get priority in the event ofconflict.Conflict is resolved by rolling back andrestarting transaction.No locks so no deadlock.

Pearson Education © 2014 51

Timestamping

TimestampA unique identifier created by DBMS thatindicates relative starting time of a transaction.

Can be generated by using system clock attime transaction started, or by incrementinga logical counter every time a newtransaction starts.

Pearson Education © 2014 52

Timestamping

Read/write proceeds only if last update onthat data item was carried out by an oldertransaction.Otherwise, transaction requesting read/writeis restarted and given a new timestamp.Also timestamps for data items:

read-timestamp - timestamp of last transactionto read item;write-timestamp - timestamp of last transactionto write item.

Pearson Education © 2014 53

Timestamping - Read(x)

ts(T) < write_timestamp(x)

x already written by younger transaction.Abort and Restart the transaction.

Otherwise, operation is accepted andexecuted. Update the read_timestamp =max((ts(T), read_timestamp(x))

Pearson Education © 2014 54

Timestamping –Transaction issues Write(x)

Consider a transaction T with timestampts(T):

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

ts(T) < read_timestamp(x)x already read by younger transaction.Roll back transaction and restart it using a latertimestamp.Otherwise proceed and set write_stamp = ts(T)

Pearson Education © 2014 55

Example – Basic Timestamp Ordering

Pearson Education © 2014 56

Comparison of Methods

Pearson Education © 2014 57

Granularity of Data Items

Size of data items chosen as unit ofprotection by concurrency control protocol.Ranging from coarse to fine:

The entire database.A file.A page (or area or database spaced).A record.A field value of a record.

Pearson Education © 2014 58

Granularity of Data Items

Tradeoff:coarser, the lower the degree of concurrency;finer, more locking information that is neededto be stored.

Best item size depends on the types oftransactions.

Pearson Education © 2014 59

Hierarchy of Granularity

Could represent granularity of locks in ahierarchical structure.Root node represents entire database, level1s represent files, etc.When node is locked, all its descendantsare also locked.DBMS should check hierarchical pathbefore granting lock.

Pearson Education © 2014 60

Hierarchy of GranularityIntention lock could be used to lock allancestors of a locked node.Intention locks can be read or write.Applied top-down, released bottom-up.

Pearson Education © 2014 61

Levels of Locking

Pearson Education © 2014 62

Database Recovery

Process of restoring database to a correctstate in the event of a failure.

Need for Recovery ControlTwo types of storage: volatile (main memory) andnonvolatile.Volatile storage does not survive system crashes.Stable storage represents information that has beenreplicated in several nonvolatile storage media withindependent failure modes.

Pearson Education © 2014 63

Types of Failures

System crashes, resulting in loss of mainmemory.Media failures, resulting in loss of parts ofsecondary storage.Application software errors.Natural physical disasters.Carelessness or unintentional destruction ofdata or facilities.Sabotage.

Pearson Education © 2014 64

Transactions and Recovery

Transactions represent basic unit ofrecovery.Recovery manager responsible for atomicityand durability.If failure occurs between commit anddatabase buffers being flushed to secondarystorage then, to ensure durability, recoverymanager has to redo (rollforward)transaction’s updates.

Pearson Education © 2014 65

Transactions and Recovery

If transaction had not committed at failuretime, recovery manager has to undo(rollback) any effects of that transaction foratomicity.Partial undo - only one transaction has to beundone.Global undo - all transactions have to beundone.

Pearson Education © 2014 66

Example

DBMS starts at time t0, but fails at time tf. Assume data fortransactions T2 and T3 have been written to secondarystorage.T1 and T6 have to be undone. In absence of any otherinformation, recovery manager has to redo T2, T3, T4, and T5.

Pearson Education © 2014 67

Recovery Facilities

DBMS should provide following facilities toassist with recovery:

Backup mechanism, which makes periodic backupcopies of database.Logging facilities, which keep track of current stateof transactions and database changes.Checkpoint facility, which enables updates todatabase in progress to be made permanent.Recovery manager, which allows DBMS to restoredatabase to consistent state following a failure.

Pearson Education © 2014 68

Log File

Contains information about all updates todatabase:

Transaction records.Checkpoint records.

Often used for other purposes (for example,auditing).

Pearson Education © 2014 69

Log File

Transaction records contain:Transaction identifier.Type of log record, (transaction start, insert, update, delete, abort, commit).Identifier of data item affected by database action (insert, delete, and update operations).Before-image of data item.After-image of data item.Log management information.

Pearson Education © 2014 70

Sample Log File

Pearson Education © 2014 71

Log File

Log file may be duplexed or triplexed.Log file sometimes split into two separaterandom-access files.Potential bottleneck; critical in determiningoverall performance.

Pearson Education © 2014 72

CheckpointingCheckpoint

Point of synchronization between database andlog file. All buffers are force-written tosecondary storage.

• Checkpoint record is created containingidentifiers of all active transactions.

• When failure occurs, redo all transactionsthat committed since the checkpoint andundo all transactions active at time of crash.

Pearson Education © 2014 73

Checkpointing

In previous example, with checkpoint at timetc, changes made by T2 and T3 have beenwritten to secondary storage.Thus:

only redo T4 and T5,undo transactions T1 and T6.

Pearson Education © 2014 74

Recovery Techniques

If database has been damaged:Need to restore last backup copy of database andreapply updates of committed transactions usinglog file.

If database is only inconsistent:Need to undo changes that caused inconsistency.May also need to redo some transactions to ensureupdates reach secondary storage.Do not need backup, but can restore database usingbefore- and after-images in the log file.

Pearson Education © 2014 75

Main Recovery Techniques

Three main recovery techniques:

Deferred UpdateImmediate UpdateShadow Paging

Pearson Education © 2014 76

Deferred Update

Updates are not written to the database untilafter a transaction has reached its commitpoint.If transaction fails before commit, it will nothave modified database and so no undoingof changes required.May be necessary to redo updates ofcommitted transactions as their effect maynot have reached database.

Pearson Education © 2014 77

Immediate Update

Updates are applied to database as theyoccur.Need to redo updates of committedtransactions following a failure.May need to undo effects of transactionsthat had not committed at time of failure.Essential that log records are written beforewrite to database. Write-ahead log protocol.

Pearson Education © 2014 78

Immediate Update

If no “transaction commit” record in log,then that transaction was active at failureand must be undone.Undo operations are performed in reverseorder in which they were written to log.

Pearson Education © 2014 79

Shadow PagingMaintain two page tables during life of atransaction: current page and shadow page table.

When transaction starts, two pages are the same.

Shadow page table is never changed thereafter andis used to restore database in event of failure.

During transaction, current page table records allupdates to database.

When transaction completes, current page tablebecomes shadow page table.

Pearson Education © 2014 80