Transactions and the Internet

Transcription

1 Transactions and the Internet Week Week MIE253-Consens 1

2 Schedule Week Date Lecture Topic 1 Jan 9 Introduction to Data Management 2 Jan 16 The Relational Model 3 Jan. 23 Constraints and SQL DDL 4 Jan. 30 SQL DML, DB Applications, JDBC 5 Feb 6 JDBC, DDL (Views, Access Control) 6 Feb 13 Relational Algebra, Advanced SQL - Feb 20 [Reading Week] 7 Feb 27 Review and Midterm (Mar 1) 8 Mar 5 OLAP 9 Mar 12 ER Conceptual Modelling 10 Mar 19 Normalization 11 Mar 26 XML and Data Integration 12 Apr 2 Transactions and the Internet, Query Processing 13 Apr 9 Final Review This week s reading: Chapters 18,20,22 Week MIE253-Consens 2

3 Transaction Processing in the WWW Browser requests information from an HTTP server Server sends to the browser an HTML page (and possibly scripts) ser interacts with the page (and scripts) and sends information back to the server Application on HTTP server (CGI, servlet, JSP, ASP.NET) reads information from the browser, processes it (accesses a database), and sends a new HTML page back to browser Week MIE253-Consens 3

4 Three-Tiered Model of TPS client machines application server machine database server machine presentation server application server DBMS presentation server communication Week MIE253-Consens 4

5 Interconnection of Servers Week MIE253-Consens 5

6 Sessions on the Internet HTTP sessions do not maintain context between interactions Context information is stored in file on Web server that is accessed through a session number Cookies: servlet places session number in a cookie file in browser; subsequent servlets can access cookie Hidden fields in HTML: servlet places session number in hidden field in HTML document it sends to browser; hidden field is not displayed but is returned with HTML document Appended field to RL (HTTP return address): session number is appended to RL return address and can be accessed by the next servlet Week MIE253-Consens 6

7 ACID Properties of Transactions Transaction execution must maintain the correctness of the database model Therefore additional requirements are placed on the execution of transactions beyond those placed on ordinary programs Atomicity (all or nothing) Consistency (w.r.t. Integrity Constraints) Isolation Durability Week MIE253-Consens 7

8 Isolation Serial execution of a set of (consistent) transactions is correct, but performance might be inadequate Concurrent (interleaved) execution of a set of transactions offers performance benefits, but might not be correct Week MIE253-Consens 8

9 Interleaved Execution Week MIE253-Consens 9

10 Incorrect Interleaved Schedule Example for course registrations: c is the number of current registrants, transaction reads and adds 1 to this number T1: r 1 (c: 29) w 1 (c: 30) T2: r 2 (c: 29) w 2 (c: 30) Schedule not equivalent to T1, T2 or T2, T1 Database state no longer corresponds to real-world state, integrity constraints are violated (but not by an isolated transaction) Week MIE253-Consens 10

11 Serializable Schedules The concurrent schedule S is serializable S: r 1 (a:4) r 2 (b:5) w 2 (a:5*2) r 1 (b:5) w 1 (c:4+5) because it is equivalent to the serial schedule T1, T2: r 1 (a:4) r 1 (b:5) w 1 (c:4+5) r 2 (b:5) w 2 (a:5*2) read operations of distinct transactions on the same data item commute S is not equivalent to T2, T1 since read and write operations (or two write operations) of distinct transactions on the same data item do not commute Week MIE253-Consens 11

12 Commutativity Two operations commute if, when executed in either order: The values returned by both are the same and The database is left in the same final state Two schedules are equivalent if one can be derived from the other by a series of simple interchanges of commutative operations A schedule is serializable if it is equivalent to a serial schedule Week MIE253-Consens 12

13 Implementing Serializability: Two-Phase Locking Locks are associated with each data item A transaction must acquire a read (shared) or write (exclusive) lock on an item in order to read or write it A write lock on an item conflicts with all other locks on the item; a read lock conflicts with a write lock If T1 requests a lock on x and T2 holds a conflicting lock on x, T1 must wait Two-Phase locking: All locks are acquired before any lock is released Week MIE253-Consens 13

14 Week MIE253-Consens 14

15 Atomicity and Durability Atomicity deals with transaction aborts: ser aborts transaction (e.g., cancel button) System aborts transaction (e.g., deadlock) Transaction aborts itself (e.g., unexpected db state) System crashes Durability deals with failure: System and Media failures Logs and backups (replicas) are the mechanisms for dealing with failures Week MIE253-Consens 15

16 Log Log: Append-only sequence of records used to restore database to a consistent state after a failure. Stored on non-volatile device distinct from mass storage device that contains database Survives processor crash and media failure To execute an pdate: Appended pdate Record to the log when a transaction modifies an item Contains before image: value of item prior to update sed to restore item when transaction is aborted Week MIE253-Consens 16

17 Aborting a Transaction Transaction abort: Scan log backward; apply before image in each of the transaction s update records to database items to restore them to their original state. Begin Record terminates scan B T1 T1 B T2 T1 T2 T1 T2 A T2 B - begin - update A - abort End of scan when T2 is aborted End of log when T2 is aborted Week MIE253-Consens 17

18 Recovery From Crash Transaction is not committed until its Commit Record is in the log A crash at any time before that causes transaction to be rolled back Active transactions must be identified and aborted when system recovers B T1 T1 B T2 T1 T2 T1 B T3 A T2 T3 C T3 B T4 T4 End of scan for crash recovery B - begin - update C - commit A - abort End of log when crash occurs; roll back T1 and T4 on recovery Week MIE253-Consens 18

19 Write-Ahead Log Both the log and database must be updated when a transaction modifies an item. If a crash occurs between updates, abort the transaction Database updated first - On recovery, item is in the new state but there is no before image to roll it back. Transaction cannot be aborted. Log updated first - On recovery, item in old state and before image in log. se of before image has no effect, but transaction can be aborted pdate record in log must be written-ahead of update to item in database Week MIE253-Consens 19

20 Summary: Transactions Architectures for TP on the Internet Two and Three Tiers Sessions ACID Properties Isolation TP Abstraction: Schedule Serializability, Anomalies, Commutativity Two-phase Locking Atomicity and Durability Logs, Recovery Week MIE253-Consens 20