1. COMP 5138 Relational Database Management Systems Semester 2, 2007 Lecture 8A Transaction Concept

2. 22 L11 TransactionManagement Definition A transaction is a collection of one or more operations on one or more databases, which reflects a single real-world transition In the real world, this happened (completely, all at once) or it didn’t happen at all Commerce examples Transfer money between accounts Purchase a group of products, and mark order as filled Student record system Register for a class (either waitlist or allocated) Many DB-based computer systems are mainly used for processing transactions

3. 33 L11 TransactionManagement Coding a transaction Typically a computer-based system doing OLTP has a collection of parameterized application programs Each program is written in a high-level language, which calls DBMS to perform individual SQL statements Either through embedded SQL converted by preprocessor Or through Call Level Interface where application constructs appropriate string and passes it to DBMS Can use program variables in queries A single SQL statement can’t do it all! Need to update several tables Need control flow logic

4. 44 L11 TransactionManagement COMMIT As app program is executing, it is “in a transaction” Program can execute COMMIT SQL command to finish the transaction successfully The next SQL statement will automatically start a new transaction Even working interactively, all activity on dbms is in a txn Each interactive SQL statement is separate txn

5. 55 L11 TransactionManagement ROLLBACK If the app gets to a place where it can’t complete the transaction successfully, it can execute ROLLBACK This causes the system to “abort” the transaction The database returns to the state without any of the previous changes made by activity of the transaction Rollback can be due to: Program request Client process death System-initiated (eg to deal with deadlock or crash)

6. 66 L11 TransactionManagement Transaction Definition in SQL Data manipulation language must include a construct for specifying the set of actions that comprise a transaction. In many DBMS such as Oracle, a transaction begins implicitly Some other DBMS provide a BEGIN TRANSACTION command A transaction in SQL ends by: Commit commits current transaction and begins a new one. Rollback causes current transaction to abort.

7. 77 L11 TransactionManagement Transaction Example Pseudocode for a product order transaction: START TRANSACTION display greeting get order request SELECT product record If product is available Then UPDATE quantityOnOrder of product record INSERT order record send message to shipping departement End if On Error: ROLLBACK COMMIT

8. 88 L11 TransactionManagement Transaction Example Transaction in Embeded SQL 1.EXEC SQL BEGIN DECLARE SECTION 2. int flight; START TRANSACTION 3. char date[10] 4. char seat [3] 5. int occ; 6.EXEC SQL END DECLARE SECTION 7.Void chooseSeat() { 8./*C code to prompt the user to enter flight, date, and seat and store these in the three variables with those name */ 9.EXEC SQL Select occupied into :occ 10. From Flights 11. Where fltNum=:flight and fltDate=:date and fltSeat=:seat; 12. If (!occ) { 13. EXEC SQL Update Flights 14. Set occupied = true 15. Where fltNum=:flight and fltDate=:date and fltSeat=:seat; 16./*C and SQL code to record the seat assignment and inform the user of the assignment */ 17.} 18.Else /* C code to notify user of unavailability and ask for another seat selection */ 19.}

9. 99 L11 TransactionManagement Atomicity Two possible outcomes for a transaction It commits: all the changes are made It aborts: no changes are made That is, transaction’s activities are all or nothing Also, the decision is irrevocable; so once committed, the transaction can’t revert to aborted Changes are durable

10. 1010 L11 TransactionManagement Integrity A real world state is reflected by collections of values in the tables of the DBMS But not every collection of values in a table makes sense in the real world The state of the tables is restricted by integrity constraints Perhaps, but not always, declared explicitly in the database schema Eg foreign key constraint, primary key constraint

11. 1111 L11 TransactionManagement Consistency Each transaction can be written on the assumption that all integrity constraints hold in the data, before the transaction runs It must make sure that its changes leave the integrity constraints still holding However, there are allowed to be intermediate states where the constraints do not hold A transaction that does this, is called consistent This is an obligation on the programmer Usually the organization has a testing/checking and sign-off mechanism before an application program is allowed to get installed in the production system

12. 1212 L11 TransactionManagement System threats to data integrity Need for application rollback Previous state must be re-installed System crash Due to buffering, state after crash may be weird mix of pages: obsolete, over-fresh, accurate Concurrent activity Data interference; avoided by isolation The system has mechanisms to handle these

13. 1313 L11 TransactionManagement Isolation To make precise what it means to have no data interference, we say that an execution is serializable when There exists some serial (ie batch, no overlap at all) execution of the same transactions which has the same final state Hopefully, the real execution runs faster than the serial one! NB: different serial txn orders may behave differently; we ask that some serial order produces the given state Other serial orders may give different final states

14. 1414 L11 TransactionManagement ACID Properties When transactions execute, users want to think of each as a single meaningful operation The programmer and the system infrastructure together should ensure the ACID properties Atomic (provided by infrastructure, provided programmer puts transaction boundaries in the right place) Consistent (provided by programmer) Isolated (provided by infrastructure, provided programmer asks for it) Durable (provided by infrastructure)