Database Transactions ACID properties Recoverable Schedule Lock Based Protocols Time Stamp-ordering protocol

Pseudo code for a DB transaction stored_procedure_add_New_members() begin @newMembers = SP_getNewMembers(); while ($member = @newMembers(next); SP_addMember($member); end notes: If there are 2000 new member to add and the first 1500 get added and then there is some error, well that’s swill better that nothing. We just try to get the other 500 in later If this transaction is partially done, we’ll take it…something is better that nothing. There is no point in deleting the entered members just because some other members didn’t make it

Pseudo code for a DB transaction Transaction_transfer100 begin float savings_balance, checking_balance SP_read (savings_balance); savings_balance = savings_balance – 100; SP_write (savings_balance); SP_read (checking_balance); checking_balance = checking_balance + 100; SP_write (checking_balance); end notes: - The reads and writes are stored procedures that will read and write from the database. - The a =a+n are operations done in main memory. - If the subtraction of 100 from savings is successful but the adding 100 to checking fails, should we be ok?

Database Transaction A database transaction is a collections (more than 1) of reads and writes to a database the MUST either ALL happen or None happen. There is no concept of “well some if it went through, so that’s better than nothing” Question: if a transaction runs completely without any failures, are it’s results considered valid?

Consider 2 Transactions Savings = $1000 Checking = $0 T1) transfer $100 from savings to checking T2) give 5% interest all accounts Transaction schedule T1 T2 savings) $945 checking) $105 Total) $1050 Transaction schedule T2 T1 savings) $950 checking) $100 Total) $1050 Either schedule is consistent with the 2 transactions intention

Multiprocessing System This T1 – part1  T2  T1 part 2 schedule produces Savings) $945 Checking) $100 Total) $1045 No Good!! However every transaction completed without errors

ACID properties of Transactions Atomicity - Either all operations of the transaction are reflected properly in the database, or none are Consistency - Execution of a transaction in isolation preserves the consistency of the database 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 Tj started executing after Ti finished. That is, each transaction is unaffected by the others running concurrently with it. Durability - After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures.

Transfer/interest ACID Atomicity – either the transfer and interest are recorded in the database, or it was not. Consistency – the sum of savings and checking plus interest match the total the customer should have. Isolation – There must be no effects of transactions that are running concurrently (either 945/105 or 950/100). Durability – once the customer is notified of the successful completion of the transaction, no system failure will result in a loss of data for this transaction. For now, assume that once data is written to disk, it will never be lost.

Recoverable Schedule A schedule of a set of transactions in the order in which all the instructions from all the transactions happened to run in that particular day, on the multiprocessing/multiprogramming database system. A recoverable schedule is one where, for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the commit operation of Ti appears before the commit operations of Tj.

Cascadeless Schedules Even if a schedule is recoverable, to recover correctly from the failure of a transaction, we may have to roll back several transactions. If T3 needs T2 to commit before T3 can commit, and T2 needs T1 to commit before T2 can commit, and then T1 fails, T3 must be rolled back, then T2 must be rolled back and then T1 needs to be rolled back. This is called a cascading rollback. Cascading rollbacks are undesirable, since they lead to undoing of a significant amount of work. The goal is to allow schedules that are cascadeless.

Commit and Rollback A data-manipulation language (DML) must include a construct for specifying the set of actions that constitute a transaction. Transactions begin implicitly, (i.e. no “begin” is needed). Transactions are ended by one of these SQL statements: Commit work commits the current transaction and begins a new one. Rollback work causes the current transitions to abort. If a transaction Ti fails, for whatever reason, we need to undo the effect of this transaction to ensure the atomicity property of the transaction. We need to place restrictions on the type of schedules permitted in the system.

Serializability (Precedence) Graph A precedence graph is a directed graph where each node is a transaction, and there is a directed edge from Ti to Tj if Ti wrote a value that Tj later read (or wrote). As transactions enter the database system, a node is created for that transaction and is added to the system precedence graph. When Ti reads or writes a field previously written by Tj, an arrow from Ti  Tj is added to the graph. Ti is now dependent on Tj. When a transaction wants to commit, the node must have only outgoing edges in the graph and if so, the node it removed from the graph along with the out-going edges.

Serializability (Precedence) Graph T1 depends on T2 and T3 completing successfully T2 depends on T1 and T3 completing successfully T3 doesn’t depend on any transaction

Transaction States Active – initial state, it stays in this state while executing. Partially committed – after the final statement has been executed. Failed – after the discovery that normal execution can no longer proceed. Aborted – after the transaction has been rolled back and the database has been restored to its state prior to the start of the transaction. Committed – after successful completion.

Transaction State diagram

Shadow Copy Before a transaction that wants to update the database begins, the transaction makes a copy of the database called the shadow copy, then make updates to the real database. If during the transaction, it is aborted, we simply copy the shadow copy of the database back on top of the real database.

Lock Based Protocols One way to ensure serializability is to require that the data items be accessed in a mutually exclusive manner. A lock() is a request to the database system, that the use of a database field(s) temporarily disallowed by all other transactions and users until the resource is unlocked. Shared locks prevent other transactions from writing the data, but allow other transactions to read it. Exclusive locks prevent other transactions from reading and writing the data. If we were to use locks in the balance transfer example, we might have the schedule:

Lock based protocol code

Deadlocks 4 necessary conditions for deadlock Both locking protocols introduce the issue of deadlocks into the system. 4 necessary conditions for deadlock Mutual Exclusion – The system allow resources to be locked out form others use. Hold and Wait – Transaction is allowed to hold one lock while waiting for another. No Pre-emption – Transactions can not be pre-empted by the system. Circular Chain – These is a cycle of transaction that are waiting for the next in the cycle. Deadlock Avoidance Managing the system in a way that prevents the system form having all 4 of the above conditions at one time (i.e. disallow at lease one of the above 4 conditions Deadlock Detection Allowing the system to move into a deadlock state, but then detecting it and then breaking the system out of the deadlock.

Two-Phase Locking Locks are acquired in two phases. The Growing phase is section of the transaction in which the locks are gotten. The Shrinking phase is when the locks are releases. The growing phase must be completed prior to the shrinking phase starting when following the 2PL protocol. This method will guarantee serializability.

Strict Two-Phase Locking Same as the 2PL protocol except that the very first steps a transaction takes is to get all locks that are needed and the last steps is to release the locks. This method will guarantee serializability and that there will be no need to rollback transactions due to any read-write conflicts.

Time Stamp-ordering protocol With each transaction Ti in the system, we associate a unique fixed timestamp, denoted by TS(Ti). This timestamp is assigned by the database system before the transaction Ti starts execution. Either by: System clock – timestamp on the system or Logical counter – increments after each new timestamp has been assigned. W-timestamp(Q) – largest timestamp of any transaction that executed write(Q) successfully. R-timestamp(Q) – largest timestamp of any transaction that executed read(Q) successfully.

Transactions commits At TS1 A R(X), TS2 A W(X), TS3 B W(Y), TS4 C R(X) TS5 C W(X) TS6 A R(Y) TS7 A W(Y) Because B wrote a field that A previously wrote, The database must reflect that A ran in it’s entirety prior to B starting therefore B  A. Because C read a field that A previously wrote CA Because A read Y that B previously wrote A  B A and B are in the (transfer/interest) situation and must be un-done, taking C down with them.