+ All Categories
Home > Documents > Lecture 9Post

Lecture 9Post

Date post: 02-Feb-2016
Category:
Upload: arpit-singh
View: 225 times
Download: 0 times
Share this document with a friend
Description:
Transacction
44
ITEC 3220A Using and Designing Database Systems Instructor: Prof. Z. Yang Course Website: http://people.yorku.ca/ ~zyang/itec3220a.htm Office: TEL 3049
Transcript
Page 1: Lecture 9Post

ITEC 3220AUsing and Designing Database Systems

Instructor: Prof. Z. YangCourse Website: http://people.yorku.ca/~zyang/itec3220a.htm Office: TEL 3049

Page 2: Lecture 9Post

Chapter 10

Transaction Management and Concurrent Control

Page 3: Lecture 9Post

3

What is a Transaction?

• Any action that reads from and/or writes to a database may consist of – Simple SELECT statement to generate

a list of table contents

– A series of related UPDATE statements to change the values of attributes in various tables

– A series of INSERT statements to add rows to one or more tables

– A combination of SELECT, UPDATE, and INSERT statements

Page 4: Lecture 9Post

4

What is a Transaction? (continued)

• A logical unit of work that must be either entirely completed or aborted

• Successful transaction changes the database from one consistent state to another– One in which all data integrity constraints

are satisfied

• Most real-world database transactions are formed by two or more database requests– The equivalent of a single SQL statement in

an application program or transaction

Page 5: Lecture 9Post

5

• 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 6: Lecture 9Post

6

• 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 7: Lecture 9Post

7

Incomplete Transactions

• Reasons:– An anomaly arises during

execution (automatically restart)– System crashes– An unexpected situation during

transaction execution

• May bring database to inconsistent state

Page 8: Lecture 9Post

8

• Atomicity – All transaction operations must be

completed– Incomplete transactions aborted

• Durability – Permanence of consistent database state

• 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

Page 9: Lecture 9Post

9

• 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 10: Lecture 9Post

10

• 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 11: Lecture 9Post

11

Transaction LogExample

Page 12: Lecture 9Post

12

Example

• Suppose that you are a manufacturer of product ABC, which is composed of parts A, B, C. Each time a new product ABC is created, it must be added to the product inventory, using the PROD_QOH in PRODUCT table. And each time the product is created the parts inventory, using PART_QOH in PART table must be reduced by one each of parts, A, B, and C.

PROD_CODE PROD_QOH

ABC 1205

PRODUCTPARTPART_CODE PART_QOH

A 567

B 98

C 549

Page 13: Lecture 9Post

13

Example (Cont’d)

Given the information, answer:• How many database requests can you

identify for an inventory update for both PRODUCT and PART?

• Using SQL, write each database request you have identified above.

• Write the complete transactions.• Write the transaction log, using the

template in slide 11.

Page 14: Lecture 9Post

14

• 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 15: Lecture 9Post

15

Normal Execution of Two Transactions

Page 16: Lecture 9Post

16

Lost Updates

Page 17: Lecture 9Post

17

More Example

Page 18: Lecture 9Post

18

Correct Execution of Two Transactions

Page 19: Lecture 9Post

19

An Uncommitted Data Problem

Page 20: Lecture 9Post

20

Retrieval During Update

Page 21: Lecture 9Post

21

Transaction Results: Data Entry Correction

Page 22: Lecture 9Post

22

Inconsistent Retrievals

Page 23: Lecture 9Post

23

Example

• A department store runs a multiuser DBMS on a local area network file server which does not enforce concurrency control. One customer has a balance due of $250 when the following three transactions related to this customer were processed at the same time:

–Payment of $250–Purchase on credit of $100–Merchandise return of $50.

Each transaction reads the customer record when the balance was $250. the updated record was returned to the database in the order shown above.

• What balance will be for the customer after the last transaction was completed?

Page 24: Lecture 9Post

24

• 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 25: Lecture 9Post

25

Read/Write Conflict Scenarios:

Page 26: Lecture 9Post

26

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 27: Lecture 9Post

27

Locking Mechanisms

• Locking level:– Database – used during database

updates– Table – used for bulk updates– Block or page – very commonly

used– Row – only requested row; fairly

commonly used– Field – requires significant

overhead; impractical

Page 28: Lecture 9Post

28

Locking Granularity

• Granularity refers to the level of the database item locked.

• A trade-off between overhead and waiting.

• Holding locks at a fine level decreases waiting among users but increase the system overhead.

• Holding locks at a coarser level reduces the number of locks but increases the amount of waiting.

Page 29: Lecture 9Post

29

A Database-Level Locking Sequence

Page 30: Lecture 9Post

30

An Example of a Table-Level Lock

Page 31: Lecture 9Post

31

Example of a Page-Level Lock

Page 32: Lecture 9Post

32

An Example of a Row-Level Lock

Page 33: Lecture 9Post

33

• 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 34: Lecture 9Post

34

An Example of a Binary Lock

Page 35: Lecture 9Post

35

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 36: Lecture 9Post

36

Shared/Exclusive Locks (Cont’d)

X S _

X No No Yes

S No Yes Yes

_ Yes Yes Yes

T1T2

Page 37: Lecture 9Post

37

Two-Phase Lockingto Ensure Serializability

• Defines how transactions acquire and relinquish locks

• Guarantees serializability, but it does not prevent deadlocks

– Growing phase, in which a transaction acquires all the required locks without unlocking any data

– Shrinking phase, in which a transaction releases all locks and cannot obtain any new lock

Page 38: Lecture 9Post

38

Two-Phase Lockingto Ensure Serializability

(continued)

• Governed by the following 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—that is, until the transaction is in its locked point

Page 39: Lecture 9Post

39

Two-Phase Locking Protocol

Page 40: Lecture 9Post

40

Deadlocks

• Condition that occurs when two transactions wait for each other to unlock data

• Possible only if one of the transactions wants to obtain an exclusive lock on a data item– No deadlock condition can exist among shared

locks

• Control through – Prevention – Detection – Avoidance

Page 41: Lecture 9Post

41

How a Deadlock Condition Is Created

Page 42: Lecture 9Post

42

Example on Concurrency Control

T1 T2 T3

R(A)

W(B)

W(A)

Commit A, B

W(B)

Commit B

W(B)

Commit B

Given schedule S1 as follows, and the locks won’t be released until commit. Is there any deadlock in S1 using Shared/Exclusive lock.

Page 43: Lecture 9Post

43

More Examples

• Let transactions T1, T2, and T3 be defined to perform the following operations:T1: Add one to AT2: Double AT3: Display A and then set A to one

• Suppose the structure for T1, T2, T3 is indicated below. If the transactions execute without any locking, please give an example of wrong schedules.

Page 44: Lecture 9Post

44

More Examples (Cont’d)

T1 T2 T3

T11:Read (A), A ← A+1T12:Update (A)

T21:Read (A), A ← A*2T22:Update (A)

T31:Read (A), A = 1T32:Update (A)

• Suppose the following scheduleT11- T31- T12- T32- T21- T22 obeyed the two-phase locking algorithm. Explain what could be produced by the schedule.


Recommended