Transaction Management ACID properties Recoverable Schedule Lock Based Protocols Time Stamp-ordering protocol

Example Ti: // a balance transfer of $100 from savings to checking read (savings_balance); savings_balance = savings_balance – 100; write (savings_balance); read (checking_balance); checking_balance = checking_balance + 100; write (checking_balance); notes: - The reads and writes imply reading and writing to disk. - The a =a+n are operations done in main memory.

ACID properties 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.

Savings to checking transfer ACID Atomicity – either the transfer is recorded in the database, or it was not. Consistency – the sum of savings and checking are the same. Isolation – There must be no effects of transactions that are running concurrently. 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.

Example) 2 transactions - Savings = $1000 Checking = $0 T1) transfer $100 from savings to checking T2) give 5% interest all both accounts Transaction schedule T1 T2 savings) $945 checking) $105 total) $1050 Transaction schedule T2 T1 savings) $950 checking) $100 total) $1050 Either schedule if consistent with the transactions intention

Multiprocessing System This T1 – part1  T2  T1 part 2 schedule produces savings) $945 checking) $100 total) $1045

Recoverable Schedule A schedule of a set of transactions is 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 it leads 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. As transactions enter the database system, a node is created for that transaction and is added to the system precedence graph. 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

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 operating system, that the use of a system resource be temporarily disallowed by all other transactions until the resource is unlocked. In database systems, the resources are data on disk. Shared locks prevent other transactions from writing the data, but allow other transactions to read it. Exclusive locks prevent other transactions form 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

Lock Manager

Deadlocks Deadlocks 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 Advoicance 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 Here, transaction C is partially committed, but need to wait for A to finish before it can commit. A fails because B performed a write of Y and A later did a read of Y but A started before B. Therefore, A must roll back which causes C to be rolled back before A can be rolled back. B finishes without a problem.