Presentation is loading. Please wait.

Presentation is loading. Please wait.

ITEC 3220A Using and Designing Database Systems Instructor: Gordon Turpin Course Website: www.cse.yorku.ca/~gordon/itec3220S07 Office: CSEB3020.

Similar presentations


Presentation on theme: "ITEC 3220A Using and Designing Database Systems Instructor: Gordon Turpin Course Website: www.cse.yorku.ca/~gordon/itec3220S07 Office: CSEB3020."— Presentation transcript:

1 ITEC 3220A Using and Designing Database Systems Instructor: Gordon Turpin Course Website: www.cse.yorku.ca/~gordon/itec3220S07 Office: CSEB3020

2 Chapter 10 Transaction Management and Concurrent Control

3 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

4 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

5 5 Examine current account balance Consistent state after transaction No changes made to Database Example Transaction SELECT ACC_NUM, ACC_BALANCE FROM CHECKACC WHERE ACC_NUM = ‘0908110638’;

6 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 PRODUCT SET PROD_QOH = PROD_QOH - 100 WHERE PROD_CODE = ‘X’; UPDATE ACCT_RECEIVABLE SET ACCT_BALANCE = ACCT_BALANCE + 500 WHERE ACCT_NUM = ‘Y’;

7 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

8 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

9 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

10 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

11 11 Transaction Log Example

12 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_CODEPROD_QOH ABC1205 PRODUCT PART PART_CODEPART_QOH A567 B98 C549

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

14 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

15 15 Normal Execution of Two Transactions

16 16 Lost Updates

17 17 More Example

18 18 Correct Execution of Two Transactions

19 19 An Uncommitted Data Problem

20 20 Retrieval During Update

21 21 Transaction Results: Data Entry Correction

22 22 Inconsistent Retrievals

23 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?

24 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

25 25 Read/Write Conflict Scenarios:

26 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

27 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

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

29 29 A Database-Level Locking Sequence

30 30 An Example of a Table-Level Lock

31 31 Example of a Page-Level Lock

32 32 An Example of a Row-Level Lock

33 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

34 34 An Example of a Binary Lock

35 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

36 36 Shared/Exclusive Locks (Cont’d) XS _ XNo Yes SNoYes _ T1 T2

37 37 Two-Phase Locking to 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

38 38 Two-Phase Locking to 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

39 39 Two-Phase Locking Protocol

40 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

41 41 How a Deadlock Condition Is Created

42 42 Example on Concurrency Control T1T2T3 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.

43 43 More Example T1T2T3 R(C) R(B) W(B) R(B) R(A) W(A) W(C) W(B) R(A) R(B) W(B) W(A) Commit A Commit A, B & C Commit B

44 44 More Example Let transactions T1, T2, and T3 be defined to perform the following operations: T1: Add one to A T2: Double A T3: 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.

45 45 More Examples (Cont’d) T1T2T3 T11: Read (A), A ← A+1 T12: Update (A) T21: Read (A), A ← A*2 T22: Update (A) T31: Read (A), A = 1 T32: Update (A) Suppose the following schedule T11- T31- T12- T32- T21- T22 obeyed the two-phase locking algorithm. Explain what could be produced by the schedule.

46 46 Concurrency Control with Time Stamping Methods Assigns a global unique time stamp to each transaction Produces an explicit order in which transactions are submitted to the DBMS Uniqueness –Ensures that no equal time stamp values can exist Monotonicity –Ensures that time stamp values always increase

47 47 Wait/Die and Wound/Wait Schemes Wait/die –Older transaction waits and the younger is rolled back and rescheduled Wound/wait –Older transaction rolls back the younger transaction and reschedules it

48 48 Wait/Die and Wound/Wait Concurrency Control Schemes

49 49 Example T1T2 R(A) W(A) W(B) W(C) R(C) Concurrency control is implemented based on time stamping method. Consider the following schedule:

50 50 Concurrency Control with Optimistic Methods Optimistic approach –Based on the assumption that the majority of database operations do not conflict –Does not require locking or time stamping techniques –Transaction is executed without restrictions until it is committed –Phases are read, validation, and write

51 51 Better Performance than Locking

52 52 Example T1T2 R(A) W(A) R(B) commit

53 53 Database Recovery Management Database recovery –Restores database from a given state, usually inconsistent, to a previously consistent state –Based on the atomic transaction property All portions of the transaction must be treated as a single logical unit of work, in which all operations must be applied and completed to produce a consistent database –If transaction operation cannot be completed, transaction must be aborted, and any changes to the database must be rolled back (undone )

54 54 Transaction Recovery Deferred write –Transaction operations do not immediately update the physical database –Only the transaction log is updated –Database is physically updated only after the transaction reaches its commit point using the transaction log information Write-through –Database is immediately updated by transaction operations during the transaction’s execution, even before the transaction reaches its commit point

55 55 Example Describe the restart work if transaction T1 is committed after the checkpoint but prior to the failure. Assume that the recovery manager uses –the deferred update approach –The write though approach BackupCheckpointFailure T1

56 56 Review Transaction property Transaction log Potential problems in multiuser environments Different locking methods and how they work Database recovery management


Download ppt "ITEC 3220A Using and Designing Database Systems Instructor: Gordon Turpin Course Website: www.cse.yorku.ca/~gordon/itec3220S07 Office: CSEB3020."

Similar presentations


Ads by Google