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.


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.


Example Transaction


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.


State Transition Diagram for Transaction


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.


DBMS Transaction Subsystem


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.


Need for Concurrency Control

Three examples of potential problemscaused by concurrency:

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


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.


Lost Update Problem

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


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.


Uncommitted Dependency Problem

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


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


Inconsistent Analysis Problem

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


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.


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.


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.


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.


Example of Conflict Serializability


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.


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.


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.


Example – Not (conflict serializable schedule)


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


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.


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.


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.


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.


Locking - Basic Rules

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


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) }



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.



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.


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.


Preventing Lost Update Problem using 2PL


Preventing Uncommitted Dependency Problemusing 2PL


Preventing Inconsistent Analysis Problem using 2PL


Cascading Rollback

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


Cascading Rollback


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.


Deadlock

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


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


Deadlock

Three general techniques for handlingdeadlock:

Timeouts.Deadlock prevention.Deadlock detection and recovery.


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.


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


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.


Example - Wait-For-Graph (WFG)


Recovery from Deadlock Detection

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

avoiding starvation.


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.


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.


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.


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


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)


Example – Basic Timestamp Ordering


Comparison of Methods


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.


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.


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.


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.


Levels of Locking


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.


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.


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.


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.


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.


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.


Log File

Contains information about all updates todatabase:

Transaction records.Checkpoint records.

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


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.


Sample Log File


Log File

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


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.


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.


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.


Main Recovery Techniques

Three main recovery techniques:

Deferred UpdateImmediate UpdateShadow Paging


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.


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.


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.


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.


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

Documents