Transaction concurrency control

44
Transaction Management and Concurrency Control

description

 

Transcript of Transaction concurrency control

Page 1: Transaction concurrency control

Transaction Management and Concurrency Control

Page 2: Transaction concurrency control

2

• Logical unit of work • Must be either entirely completed or aborted• No intermediate states are acceptable

What is a Transaction?

Figure 9.1

Page 3: Transaction concurrency control

3

• Examine current account balance

• Consistent state after transaction• No changes made to Database

Example Transaction

SELECT ACC_NUM, ACC_BALANCEFROM CHECKACCWHERE ACC_NUM = ‘0908110638’;

Page 4: Transaction concurrency control

4

• Register credit sale of 100 units of product X to customer Y for $500

• Consistent state only if both transactions are fully completed

• DBMS doesn’t guarantee transaction represents real-world event

Example Transaction

UPDATE PRODUCTSET PROD_QOH = PROD_QOH - 100WHERE PROD_CODE = ‘X’;UPDATE ACCT_RECEIVABLESET ACCT_BALANCE = ACCT_BALANCE + 500WHERE ACCT_NUM = ‘Y’;

Page 5: Transaction concurrency control

5

• Atomicity – All transaction operations must be completed– Incomplete transactions aborted

• Durability – Permanence of consistent database state

• Consistency / Serializability – Conducts transactions in serial order– Important in multi-user and distributed databases

• Isolation – Transaction data cannot be reused until its execution

complete

Transaction Properties (ACID)

Page 6: Transaction concurrency control

6

Example of Fund Transfer

• Transaction to transfer $50 from account A to account B:1. read(A)

2. A := A – 50

3. write(A)

4. read(B)

5. B := B + 50

6. write(B)

Page 7: Transaction concurrency control

7

Example of Fund Transfer

• Consistency requirement – the sum of A and B is unchanged by the execution of the transaction.

• Atomicity requirement — if the transaction fails after step 3 and before step 6, the system should ensure that its updates are not reflected in the database, else an inconsistency will result.

Page 8: Transaction concurrency control

8

Example of Fund Transfer

• Durability requirement — once the user has been notified that the transaction has completed (i.e., the transfer of the $50 has taken place), the updates to the database by the transaction must persist despite failures.

Page 9: Transaction concurrency control

9

Example of Fund Transfer

• Isolation requirement — if between steps 3 and 6, another transaction is allowed to access the partially updated database, it will see an inconsistent database

(the sum A + B will be less than it should be).Can be ensured by running transactions serially, that is one after the other.

Page 10: Transaction concurrency control

10

Transaction state

• Active– the initial state; the transaction stays in this state

while it is executing• Partially committed

– after the final statement has been executed.• Failed

– after the discovery that normal execution can no longer proceed.

Page 11: Transaction concurrency control

11

Transaction state

• Aborted – after the transaction has been rolled back and the

database restored to its state prior to the start of the transaction. Two options after it has been aborted:

• restart the transaction – only if no internal logical error

• kill the transaction

• Committed, after successful completion.

Page 12: Transaction concurrency control

12

DBMS Transaction Subsystem

Transaction Manager

Scheduler/ Lock

Manager

Recovery Manager

Buffer Manager

File Manager

Access Manager

Systems Manager

Database and system

catalog

Database Manager

Page 13: Transaction concurrency control

13

DBMS Transaction Subsystem

• Trans. Mgr. – coordinates transactions on behalf of application

program. It communicates with scheduler.

• Scheduler – implements a strategy for concurrency control.

• Recovery manager – If any failure occurs, recovery manager handles it.

• Buffer manager – in charge of transferring data between disk storage and

main memory.

Page 14: Transaction concurrency control

14

DBMS Transaction Subsystem

• File manager – manipulates the underlying storage files and manages

the allocation of storage space on disk.

• Access manager – File manager does not directly manage the physical

input and output of data, rather it passes the requests on to the access manager.

• System manager – Appropriate access method is used to either read or

write data into the system manager.

Page 15: Transaction concurrency control

15

• Transaction support– COMMIT

– ROLLBACK

• User initiated transaction sequence must continue until: – COMMIT statement is reached

– ROLLBACK statement is reached

– End of a program reached

– Program reaches abnormal termination

Transaction Management with SQL

Page 16: Transaction concurrency control

16

• Tracks all transactions that update database• May be used by ROLLBACK command• May be used to recover from system failure• Log stores

– Record for beginning of transaction– Each SQL statement

• Operation• Names of objects• Before and after values for updated fields• Pointers to previous and next entries

– Commit Statement

Transaction Log

Page 17: Transaction concurrency control

17

Transaction Log Example

Table 9.1

Page 18: Transaction concurrency control

18

• Coordinates simultaneous transaction execution in multiprocessing database– Ensure serializability of transactions in multiuser

database environment

– Potential problems in multiuser environments• Lost updates• Uncommitted data• Inconsistent retrievals

Concurrency Control

Page 19: Transaction concurrency control

19

Lost Updates

Table 9.2

Table 9.3

Page 20: Transaction concurrency control

20

Uncommitted Data

Table 9.5

Table 9.4

Page 21: Transaction concurrency control

21

Inconsistent Retrievals

Table 9.6

Table 9.7

Page 22: Transaction concurrency control

22

Inconsistent Retrievals (con’t.)

Table 9.8

Page 23: Transaction concurrency control

23

• Establishes order of concurrent transaction execution

• Interleaves execution of database operations to ensure serializability

• Bases actions on concurrency control algorithms– Locking

– Time stamping

• Ensures efficient use of computer’s CPU

The Scheduler

Page 24: Transaction concurrency control

24

Read/Write Conflict Scenarios:Conflicting Database Operations Matrix

Table 9.9

Page 25: Transaction concurrency control

25

Concurrency Control with Locking Methods

• Lock guarantees current transaction exclusive use of data item

• Acquires lock prior to access• Lock released when transaction is

completed • DBMS automatically initiates and enforces

locking procedures• Managed by lock manager• Lock granularity indicates level of lock use

Page 26: Transaction concurrency control

26

Database-Level Locking Sequence

Figure 9.2

Page 27: Transaction concurrency control

27

Table-Level Lock Example

Figure 9.3

Page 28: Transaction concurrency control

28

Page-Level Lock Example

Figure 9.4

Page 29: Transaction concurrency control

29

Row-Level Lock Example

Figure 9.5

Page 30: Transaction concurrency control

30

Field Level Lock

• Access same row as long as they require different fields (attributes) within that row

Page 31: Transaction concurrency control

31

Lock Types

• Binary Locks• Shared/Exclusive Locks

Page 32: Transaction concurrency control

32

• Two states– Locked (1)

– Unlocked (0)

• Locked objects unavailable to other objects– Unlocked objects open to any transaction

– Transaction unlocks object when complete

Binary Locks

Page 33: Transaction concurrency control

33

Example of Binary Lock Table

Table 9.10

Page 34: Transaction concurrency control

34

Shared/Exclusive Locks

• Shared– Exists when concurrent transactions granted READ

access – Produces no conflict for read-only transactions– Issued when transaction wants to read and exclusive

lock not held on item

• Exclusive– Exists when access reserved for locking transaction– Used when potential for conflict exists– Issued when transaction wants to update unlocked

data

Page 35: Transaction concurrency control

35

Problems with Locking

• Transaction schedule may not be serializable– Managed through two-phase locking

• Schedule may create deadlocks– Managed by using deadlock detection and

prevention techniques

Page 36: Transaction concurrency control

36

Two-Phase Locking

• Growing phase• Shrinking phase• Governing rules

– Two transactions cannot have conflicting locks

– No unlock operation can precede a lock operation in the same transaction

– No data are affected until all locks are obtained

Page 37: Transaction concurrency control

37

Two-Phase Locking Protocol

Figure 9.6

Page 38: Transaction concurrency control

38

Deadlocks

• Occurs when two transactions wait for each other to unlock data

• Called deadly embrace• Control techniques

– Deadlock prevention

– Deadlock detection

– Deadlock avoidance

Page 39: Transaction concurrency control

39

How Deadlock Conditions Created

Table 9.11

Page 40: Transaction concurrency control

40

Concurrency Control with Time Stamping Methods

• Assigns global unique time stamp to each transaction• Produces order for transaction submission• Properties

– Uniqueness– Monotonicity

• DBMS executes conflicting operations in time stamp order

• Each value requires two additional time stamps fields– Last time field read– Last update

Page 41: Transaction concurrency control

41

Concurrency Control with Optimistic Methods

• Assumes most database operations do not conflict

• Transaction executed without restrictions until committed

• Phases:– Read Phase

– Validation Phase

– Write Phase

Page 42: Transaction concurrency control

42

• Restores a database to previously consistent state

• Based on the atomic transaction property• Level of backup

– Full backup

– Differential

– Transaction log

Database Recovery Management

Page 43: Transaction concurrency control

43

• Software• Hardware• Programming Exemption• Transaction• External

Causes of Database Failure

Page 44: Transaction concurrency control

44

• Deferred-write and Deferred-update– Changes are written to the transaction log

– Database updated after transaction reaches commit point

• Write-through– Immediately updated by during execution

– Before the transaction reaches its commit point

– Transaction log also updated

– Transaction fails, database uses log information

to ROLLBACK

Transaction Recovery