1 / 26

Chapter 15: Transactions

Chapter 15: Transactions. Loc Hoang CS 157B. Definition. A transaction is a discrete unit of work that must be completely processed or not processed at all. Example: Transferring funds from a checking account to a saving account. Desirable Properties.

rigg
Télécharger la présentation

Chapter 15: Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 15: Transactions Loc Hoang CS 157B

  2. Definition • A transaction is a discrete unit of work that must be completely processed or not processed at all. • Example: Transferring funds from a checking account to a saving account.

  3. Desirable Properties • To ensure data data integrity. The database system must maintain the ACID properties. • Atomicity • Consistency • Isolation • Durability

  4. ACID continue… • Atomicity. Either all operations of the transaction are reflected properly in the database, or none are. • Consistency. Execution of a transaction in isolation (that is, with no other transaction executing concurrently) preserves the consistency of the database.

  5. ACID continue... • Isolation.Even though multiple transactions may execute concurrently, the system guarantees that, for every pair of transactions Ti, and Tj, it appears to Ti, that either Tj finished execution before Ti started, or that Tj started execution after Ti finished. Thus, each transaction is unaware of the transactions executing concurrently in the system.

  6. ACID continue... • Durability. After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures.

  7. Transaction States • Because failures occurs, transaction are broken up into states to handle various situation.

  8. Transaction States • Active, the initial state; the transaction stays in this state until while it is still executing. • A transition is terminated only if it has either been committed or aborted.

  9. Transaction States • Partially committed, After the final statement has been executed • At this point failure is still possible since changes may have been only done in main memory, a hardware failure could still occur.

  10. Transaction States • The DBMS needs to write out enough information to disk so that, in case of a failure, the system could re-create the updates performed by the transaction once the system is brought back up. After it has written out all the necessary information, it is committed.

  11. Transaction States • Committed- after successful completion. • Once committed, the transaction can no longer be undone by aborting it. • Its effect could be undone only by a compensatingtransaction.

  12. Transaction States • Failed, after the discovery that normal execution can no longer proceed • Once a transaction can not be completed, any changes that it made must be undone rolling it back.

  13. Transaction States • Aborted, after the transaction has been rolled back the the database has been restored to its state prior to the start of the transaction. • The DBMS could either kill the transaction or restart the transaction. • A transaction may only be restarted as a result of some hardware or software error, and a restarted transaction is considered a new transaction.

  14. Concurrent execution • DBMS usually allow multiple transaction to run at once. • The transaction could by run serially (one after another) or they could be interleaved(switching back and forth between transactions)

  15. Concurrent execution • Pro: • Improved throughput and resource utilization Could take advantage of multi-processsing • Reduce waiting time. Avoid short transaction waiting on long transaction Improve average response time.

  16. Concurrent execution • Con: • Creates many complications in data consistency, including cascading roll-backs. • Consistency could be compromise even if each individual transaction is correct.

  17. Schedules • DBMS needs to make sure that all transaction schedules preserves the consistency of the database. • A schedule is the chronological order in which instructions are executed in a system.

  18. Schedule • A schedule for a set of transaction must consist of all the instruction of those transaction and must preserve the order in which the instructions appear in each individual transaction.

  19. Schedule example T1 ----------------- read(A) A:=A-50 write(A) read(B) B:= B+ 50 write(B) T2 ----------------- read(A) temp: A * 0.1 A: A-temp write (A) read(B) B:=B +temp write(B) Schedule 1.

  20. Serial Schedule • In schedule 1 the all the instructions of T1 are grouped and run together. Then all the instructions of T2 are grouped and run together. This type of schedules are called serial. • Concurrent transactions do not have to run serially as in the next examples.

  21. Interleaved Schedule T1 ----------------- read(A) A:=A-50 write(A) read(B) B:= B+ 50 write(B) T2 ----------------- read(A) temp: A * 0.1 A: A-temp write (A) read(B) B:=B +temp write(B) Schedule 2

  22. Conflict Equivalent • Schedule 1 and 2 produce the same result even though they have different sequence. It could be shown that Schedule 2 could be transform into Schedule 1 with a sequence of swaps, so Schedule 1 and 2 conflict equivalent. • Not all schedules are conflict equivalent. Consider Schedule 3

  23. Inconsistent Schedule T2 ----------------- read(A) temp: A * 0.1 A: A-temp write (A) read(B) B:=B +temp write(B) T1 ----------------- read(A) A:=A-50 write(A) read(B) B:= B+ 50 write(B) Schedule 3.

  24. Serializability • Suppose that A and B were bank accounts with initial amounts of $1,000 and $2,000 respectively. Then after Schedule 1 and Schedule 2 are run. The result is $850 for A and $2,150 for B. And the sum A+B is still $3000. • After Schedule 3 runs, account A is $950 and B $2100. The sum A+B is now $3,050 which is incorrect, since $50 was magically created in the process.

  25. Conflict Serializability • Schedule 2 is consistent because is it conflict equivalent to Schedule 1. Since Schedule 1 is serial, Schedule two is said to be conflict serializable. • Instructions within a schedule could be swapped if they do not conflict. Instructions do not conflict if they access different data item or if they access the same data item non of the instructions are write instructions.

  26. Conflict Serializability • Schedule 2 could be turn into Schedule 1 with the by the following steps: • Swap write(A) of T2 with read(B) of T1 • Swap read(B) of T1 with read(A) of T2 • Swap write(B) of T1 with write(A) of T2 • Swap write(B) of T1 with read(A) of T2

More Related