Topic 6.3: Transactions and Concurrency Control Hari Uday

* Part 1: Basic Knowledge * Originally Developed for Databases, but can be applied to Distributed File management systems * Motivation is to make use of clean and powerful atomic transactions semantics [ACID]

* Transaction Services: * Clients at each distributed site issues transaction service requests to the local transaction processing system (TPS) * TPS consists of transaction manager(TM), Scheduler (SCH) and Object Manager (OM) * A transaction may invoke operations on remote objects [sub-transactions], send to remote TPS * Transaction Manager works in tandem with other TMs to make sure local as well as remote transactions work consistently. * Scheduler makes sure that scheduling is done to objects and that conflicts are avoided. * Object Manager ensures the coherency of replicas and caches and provides interface to file systems.

* Atomicity, Consistency, Isolation and Durability * Atomicity: either all actions are carried or none are. * Consistency: when a user’s transaction runs to completion by itself * against a ‘consistent’ database instance, it will leave the database in a ‘consistent’ state. * Isolation: users can understand a transaction without considering the effect of other concurrently executing transactions. * Durability: once a transaction has been successfully completed, its effects should persist even if the system crashes before all its changes are reflected on disk

* Client Process: A client initiates start of transaction by issuing a begin transaction to its local TM. Tm generates transaction ID and work space for subsequent RW operations.

* TM then sends the transaction ID to the scheduler. Called execution phase. Access requests from the TM are handled by Scheduler. To maintain atomicity, a rejected operation causes TM to abort. Finally, the TM either commits or aborts.

* SCH chooses a concurrency control protocol. * Three approaches: Prevent inconsistency or validate consistency: Locks (Shared and Exclusive) * 2 nd approach: Individual access operations is checked by the SCH and is either accepted, tentatively accepted or rejected. Timestamps are used * 3 rd approach: Conflicts are ignored in exec. phase. Consistency is validated at the end of exec. phase. Only transactions that are globally validated are allowed to commit.

* OM is responsible for interfacing with the underlying file service for actual operations on an object. * Provides cache management for efficiency * Participates in failure recovery protocols to support durability * If objects are replicated, consistency of replicas are managed by Replica Management Protocol.

* Concept of Transactions are very important in multiuser file system (NFS, NTFS) * Scheduling Transactions: A transaction is a series of actions including READs / WRITEs of files and ABORTs and COMMITs. * A schedule is a list of actions from a set of transactions, and the order in which two actions of a transaction T appear in a schedule must be the same as the order in which they appear in T * Serial schedule: Schedule that does not interleave the actions of different transactions

* Equivalent schedules: For any file system, the effect (on the set of objects in the database) of executing the first schedule is identical to the effect of executing the second schedule * Serializable schedule: A schedule that is equivalent to some serial execution of the transactions. * If each transaction preserves consistency, every serializable schedule preserves consistency

* Two actions on the same data object conflict if at least one of them is a WRITE. * – write-read (WR) conflict: T2 could read a DB object that has been modified by T1, which has not yet committed. * – read-write (RW) conflict: T2 could change the value of an object that has been read by T1, while T1 is still in progress. * – write-write (WW) conflict: T2 could overwrite the value of an object which has already been modified by T1, while T1 is still in progress.

* A serializable schedule is a schedule whose effect on any consistent database instance is guaranteed to be identical to that of some complete serial schedule over the set of committed transactions * In a recoverable schedule, transactions commit only after all transactions whose changes they read commit

* A lock is a small bookkeeping object associated with a object * A locking protocol is a set of rules to be followed by each transaction to ensure that, even though actions of several transactions might be interleaved, the net effect is identical to executing all transactions in some serial order. * Strict 2 PL Locking * Timestamp

* Strict 2PL Protocol: * Each transaction must obtain a S (shared) lock on object before reading, and an X (exclusive) lock on object before writing. * All locks held by a transaction are released when the transaction completes. * If a transaction holds an X lock on an object, no other transactions can get a lock (S or X) on that object. * Strict 2PL allows only serializable schedules

* If a transaction Ti is aborted, all its actions have to be undone. Not only that, if Tj reads an object last written * by Ti, Tj must be aborted as well. * Most systems avoid such cascading aborts by releasing a transaction’s locks only at commit time. - If Ti writes an object, Tj can read this only after Ti commits. * In order to undo the actions of an aborted transaction, the OS maintains a log in which every write is recorded. This mechanism is also used to recover from system crashes: all active transactions at the time of the crash are aborted when the system comes back up.

* The following actions are recorded in the log: – Ti writes an object: the old value and the new value. Log record must go to disk before the changed page! – Ti commits/aborts: a log record indicating this action. * Log records are chained together by transaction id, so it’s easy to undo a specific transaction * Log is often duplexed and archived on stable storage * All log related activities are handled transparently by the DBMS

* Crash Recovery * A recovery manager of is responsible for ensuring transaction atomicity and durability. * Can the changes made to an object in the buffer pool by a transaction T be written to disk before T commits? (steal?) * When a transaction commits, must all the changes it has made to objects in the buffer pool be immediately forced to disk? (force?) * Recommend: Use a steal, no-force approach.

* Three phases for recovery algorithm: * Analysis: Scan the log forward (from the most recent checkpoint) to identify all transactions that were active, and all dirty pages in the buffer pool at the time of the crash. * Redo: Redo all updates to dirty pages in the buffer pool, as needed, to ensure that all logged updates are in fact carried out and written to disk. * Undo: The writes of all transactions that were active at the crash are undone, working backwards in the log. (Some care must be taken to handle the case of a crash occurring during the recovery process!)

* Development, Visualization, and Application of the ARIES Systems Code Carlson, L. ; Center for Energy Res., Univ. of California-San Diego, La Jolla, CA, USA ; Tillack, M. ; Najmabadi, F. ; Kessel, C. Carlson, L.Tillack, M.Najmabadi, F.Kessel, C. * A model of atomicity for multilevel transactions Blaustein, B.T. ; MITRE Corp., McLean, VA, USA ; Jajodia, S. ; McCollum, C.D. ; Notargiacomo, L. Blaustein, B.T.Jajodia, S.McCollum, C.D.Notargiacomo, L.