small lecturenumber - hepage : Transactionssmall lecturenumber - hepage : Transactionssmall lecturenumber - hepage : Examplesmall lecturenumber - hepage : Example transactionsmall lecturenumber - hepage : Committing and Abortingsmall lecturenumber - hepage : ACIDsmall lecturenumber - hepage : Atomicitysmall lecturenumber - hepage : Consistencysmall lecturenumber - hepage : Isolationsmall lecturenumber - hepage : Isolationsmall lecturenumber - hepage : Durabilitysmall lecturenumber - hepage : Common problems in transaction processingsmall lecturenumber - hepage : Lost updatessmall lecturenumber - hepage : Lost updatessmall lecturenumber - hepage : Inconsistent retrievalssmall lecturenumber - hepage : Inconsistent retrievalssmall lecturenumber - hepage : Serial equivalencesmall lecturenumber - hepage : Conflicting operationssmall lecturenumber - hepage : Conflicting operationssmall lecturenumber - hepage : Lockingsmall lecturenumber - hepage : Locking examplesmall lecturenumber - hepage : Lockingsmall lecturenumber - hepage : Lockingsmall lecturenumber - hepage : Lockssmall lecturenumber - hepage : Deadlockssmall lecturenumber - hepage : Deadlock examplesmall lecturenumber - hepage : Preventing deadlocksmall lecturenumber - hepage : Detecting deadlocksmall lecturenumber - hepage : Distributed Transactionssmall lecturenumber - hepage : Nested transactionssmall lecturenumber - hepage : Nested transactionssmall lecturenumber - hepage : Committing in nested transactionssmall lecturenumber - hepage : Flat and Nested Distributed transactionssmall lecturenumber - hepage : Coordinatorssmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Two-phase commitsmall lecturenumber - hepage : Nested two-phase commitsmall lecturenumber - hepage : Failure in Two-phase commitsmall lecturenumber - hepage : Locking and Deadlocksmall lecturenumber - hepage : Distributed Deadlocksmall lecturenumber - hepage : Edge chasingsmall lecturenumber - hepage : Edge chasingsmall lecturenumber - hepage : Edge Chasing Examplesmall lecturenumber - hepage : Edge Chasing Examplesmall lecturenumber - hepage : Edge Chasing Examplesmall lecturenumber - hepage : Edge Chasing Examplesmall lecturenumber - hepage : Breaking deadlocksmall lecturenumber - hepage : SummaryDistributed Software DevelopmentTransactionsChris BrooksDepartment of Computer ScienceUniversity of San FranciscoDepartment of Computer Science — University of San Francisco – p. 1/??19-2: Transactions•Features of transactions•Serial equivalence•Locking and deadlock•Distributed transactions•Two-phase commit•Distributed deadlockDepartment of Computer Science — University of San Francisco – p. 2/??19-3: Transactions•A transaction is a sequence of operations between a client anda server.•Goal: make sure that:◦Objects remain in a consistent state◦System is tolerant to crash failures◦Transaction effects are independent of other transactions◦Transactions are either completed or not started.Department of Computer Science — University of San Francisco19-4: Example•As an example, we’ll look at an interface to a banking system.•We’d like to be able to do the following operations on accounts:◦deposit(amt)◦withdraw(amt)◦getBalance()◦setBalance(amt)•We’d also like the following operations to be available forbranches:◦CreateAccount(name)◦lookUpAccount(name)◦totalAccounts()Department of Computer Science — University of San Francisco – p. 4/??19-5: Example transaction•A transaction may involve several operations, each of whichchanges the state of a different object:◦Transaction T:1. alexAcct.withdraw(100)2. nancyAcct.deposit(100)3. nancyAcct.widthdraw(200)4. brooksAcct.deposit(200)◦We can’t stop in the middle, lose any of the operations, ordo them in the wrong order.Department of Computer Science — University of San Francisco – p. 5/??19-6: Committing and Aborting•A transaction may be either committed or aborted.•When all operations are complete and the transaction is readyto be accepted, it is committed.◦Written to permanent storage◦After this point, it cannot be undone•If the server decided that a transaction cannot be processed(undone by the client, or it will leave the system in aninconsistent state), it is aborted.◦All operations are undoneDepartment of Computer Science — University of San Francisco19-7: ACID•The desirable features of a transactional DBMS are sometimesreferred to as ACID◦Atomicity◦Consistency◦Isolation◦DurabilityDepartment of Computer Science — University of San Francisco – p. 7/??19-8: Atomicity•Atomicity is sometimes referred to as “all-or-nothing”.•Either a transaction completes successfully, and all effects areapplied to all objects, or it has no effect at all.•Either all withdraws and deposits are made, or none of themare.Department of Computer Science — University of San Francisco – p. 8/??19-9: Consistency•A transaction must move the system from consistent state toconsistent state.•For example, the sum of all the accountBalances must alwaysbe equal to the branch’s totalAccounts•Depending on the application, at database may have otherconstraints◦No negative balances on an account◦No post-dated transactions•If the system is in an inconsistent state after a transaction, thetransaction must be undone, so as to restore consistency.Department of Computer Science — University of San Francisco19-10: Isolation•The intermediate effects of a transaction must not be visible toother transactions.◦In our example, Nancy’s bank account balance briefly wentup by $100. (the money was then transferred to Brooks’account)◦No other process or transaction should see that balance.•In other words, to the outside world, a transaction must appearas a single operation.Department of Computer Science — University of San Francisco – p. 10/??19-11: Isolation•How to provide isolation?•Perform all transactions in a single thread◦Works, but doesn’t scale.•Use locks to control concurrent access.◦Better, although now we need to detect (and undo)deadlocks.Department of Computer Science — University of San Francisco – p. 11/??19-12: Durability•After a transaction has
View Full Document
Unlocking...