eec-681/781 distributed computing systems
DESCRIPTION
EEC-681/781 Distributed Computing Systems. Lecture 12 Wenbing Zhao [email protected] Cleveland State University. Outline. Project report requirement Transaction processing concepts Distributed transaction and two phase commit Midterm #2 11/12 Wednesday. Project Report Requirement. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/1.jpg)
EEC-681/781EEC-681/781Distributed Computing Distributed Computing
SystemsSystems
Lecture 12Lecture 12
Wenbing ZhaoWenbing [email protected]
Cleveland State UniversityCleveland State University
![Page 2: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/2.jpg)
22
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
OutlineOutline
• Project report requirement
• Transaction processing concepts
• Distributed transaction and two phase commit
• Midterm #2– 11/12 Wednesday
![Page 3: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/3.jpg)
33
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Project Report RequirementProject Report Requirement
• Introduction: define the problem and provide motivation why we need a solution
• Background: so that readers can understand the techniques used to solve the problem
• Current state of the art: what are the fundamental techniques used to solve the problem. Ideally, provide a taxonomy of the techniques
• Open issues and future research directions: what are the hard problems remaining to be solved?
![Page 4: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/4.jpg)
44
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Why Transaction Processing?Why Transaction Processing?
• To achieve a form of fault tolerance– If something bad happens in a middle of a set of
operations, we abort and rollback to the original state
![Page 5: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/5.jpg)
55
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Transaction and ACID PropertiesTransaction and ACID Properties
• Atomicity: All operations either succeed, or all of them fail. When the transaction fails, the state of the object will remain unaffected by the transaction.
• Consistency: A transaction establishes a valid state transition. • Isolation: Concurrent transactions do not interfere with each other.
It appears to each transaction T that other transactions occur either before T, or after T, but never both.
• Durability: After the execution of a transaction, its effects are made permanent: changes to the state survive failures.
A transaction is a collection of operations on the state of an object (database, object composition, etc.) that satisfies the following properties:
![Page 6: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/6.jpg)
66
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Primitives for TransactionsPrimitives for Transactions
Primitive Description
BEGIN_TRANSACTION Make the start of a transaction
END_TRANSACTION Terminate the transaction and try to commit
ABORT_TRANSACTION Kill the transaction and restore the old values
READ Read data from a file, a table, or otherwise
WRITE Write data to a file, a table, or otherwise
BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi;END_TRANSACTION
(a)
BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi full =>ABORT_TRANSACTION (b)
Example transactions
![Page 7: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/7.jpg)
77
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Transaction ClassificationTransaction Classification
• Flat transactions: a sequence of operations that satisfies the ACID properties (the most common one)
• Nested transactions: A hierarchy of transactions that allows– Concurrent processing of subtransactions, and – Recovery per subtransaction
• Distributed transactions: A (flat) transaction that span multiple databases distributed across the network
![Page 8: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/8.jpg)
88
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Implementation of TransactionsImplementation of Transactions
• Private workspace
• Writeahead log
![Page 9: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/9.jpg)
99
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Private WorkspacePrivate Workspace
The file index and disk blocks for a three-block file
The situation after a transaction has modified
block 0 and appended block 3
After committing
A transaction gets its own copy of the (part of the) database. When things go wrong delete copy, otherwise commit the changes to the original
![Page 10: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/10.jpg)
1010
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Writeahead LogWriteahead Log
x = 0;
y = 0;
BEGIN_TRANSACTION;
x = x + 1;
y = y + 2
x = y * y;
END_TRANSACTION;
(a)
Log
[x = 0 / 1]
(b)
Log
[x = 0 / 1]
[y = 0 / 2]
(c)
Log
[x = 0 / 1]
[y = 0 / 2]
[x = 1 / 4]
(d)
A transaction The log before & after each statement is executed
Use a writeahead log in which changes are recorded allowing one to roll back when things go wrong
![Page 11: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/11.jpg)
1111
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Concurrency Control Concurrency Control • Goal: Increase efficiency by allowing several transactions
to execute at the same time• Constraint: Effect should be the same as if the
transactions were executed in some serial order
General organization of managers for handling
transactions
![Page 12: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/12.jpg)
1212
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Concurrency Control Concurrency Control
General organization of managers for handling distributed transactions
![Page 13: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/13.jpg)
1313
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
SerializabilitySerializability
• Consider a collection E of transactions T1, … Tn• Goal is to conduct a serializable execution of E:
– Transactions in E are possibly concurrently executed according to some schedule S
– Schedule S is equivalent to some totally ordered execution of T1, … Tn
• Two operations Op(Ti, x) and Op(Tj, x) on the same data item x, and from a set of logs may conflict at a data manager:– read-write conflict (rw): One is a read operation while the other
is a write operation on x– write-write conflict (ww): Both are write operations on x
![Page 14: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/14.jpg)
1414
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Basic Scheduling TheoremBasic Scheduling Theorem
• Concurrency control - process conflicting reads and writes in certain relative orders
• Read-write and write-write conflicts can be synchronized independently, as long as we stick to a total ordering of transactions that is consistent with both types of conflicts
![Page 15: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/15.jpg)
1515
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Synchronization TechniquesSynchronization Techniques
• Two-phase locking: Before reading or writing a data item, a lock must be obtained. After a lock is released, the transaction is not allowed to acquire any more locks
• Timestamp ordering: Operations in a transaction are timestamped, and data managers are forced to handle operations in timestamp order
• Optimistic control: Don’t prevent things from going wrong, but correct the situation if conflicts actually did happen
![Page 16: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/16.jpg)
1616
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Two-Phase LockingTwo-Phase Locking
• There are only READ and WRITE operations within transactions
• Locks are granted and released only by scheduler
• Locking policy is to avoid conflicts between operations
![Page 17: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/17.jpg)
1717
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Two-phase LockingTwo-phase Locking• Rule 1: When client submits Op(Ti,x), scheduler tests
whether it conflicts with an operation Op(Tj,x) from some other client. If no conflict then grant Op(Ti,x), otherwise delay execution of Op(Ti,x)– Conflicting operations are executed in the same order as that
locks are granted
• Rule 2: If Op(Ti,x) has been granted, do not release the lock until Op(Ti,x) has been executed by data manager– Guarantees LOCK => Op => RELEASE order
• Rule 3: If RELEASE(Ti,x) has taken place, no more locks for Ti may be granted– Combined with rule 1, guarantees that all pairs of conflicting
operations of two transactions are done in the same order
![Page 18: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/18.jpg)
1818
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Two-Phase LockingTwo-Phase Locking
• Centralized 2PL: A single site handles all locks• Primary 2PL: Each data item is assigned a primary site to handle its locks. Data
is not necessarily replicated• Distributed 2PL: Assumes data can be replicated. Each primary is responsible
for handling locks for its data, which may reside at remote data managers
![Page 19: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/19.jpg)
1919
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Two-Phase Locking: ProblemsTwo-Phase Locking: Problems• Problem 1: System can come into a deadlock. How?
– Practical solution: put a timeout on locks and abort transaction on expiration.
• Problem 2: When should the scheduler actually release a lock:– (1) when operation has been executed
– (2) when it knows that no more locks will be requested
• No good way of testing condition (2) unless transaction has been committed or aborted
• Moreover: Assume the following execution sequence takes place:RELEASE(Ti,x) => LOCK(Tj,x) => ABORT(Ti).
• Consequence: scheduler will have to abort Tj as well (cascaded aborts)
• Solution: Release all locks only at commit/abort time (strict two-phase locking)
![Page 20: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/20.jpg)
2020
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Strict Two-Phase Locking Strict Two-Phase Locking
![Page 21: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/21.jpg)
2121
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Two-Phase Commit Two-Phase Commit –– Achieving Atomicity Achieving Atomicity in Distributed Transactionsin Distributed Transactions
• Model: The client who initiated the computation acts as a coordinator; processes required to commit are the participants
• Phase 1a: Coordinator sends VOTE_REQUEST to participants (also called a pre-write)
• Phase 1b: When participant receives VOTE_REQUEST it returns either YES or NO to coordinator. If it sends NO, it aborts its local computation
• Phase 2a: Coordinator collects all votes; if all are YES, it sends COMMIT to all participants, otherwise it sends ABORT
• Phase 2b: Each participant waits for COMMIT or ABORT and handles accordingly
![Page 22: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/22.jpg)
2222
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
Two-Phase Commit Two-Phase Commit
The finite state machine for the
coordinator in 2PC
The finite state machine for a
participant
![Page 23: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/23.jpg)
2323
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
2PC 2PC –– Failing Participant Failing Participant
• Initial state: No problem, as participant was unaware of the protocol
• Ready state: Participant is waiting to either commit or abort. After recovery, participant needs to know which state transition it should make => log the coordinator’s decision
• Abort state: Need to make entry into abort state idempotent
• Commit state: Also make entry into commit state idempotent
Consider participant crash in one of its states, and the subsequent recovery to that state:
![Page 24: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/24.jpg)
2424
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
2PC 2PC –– Failing Coordinator Failing Coordinator• If it fails, the final decision is not available until the
coordinator recovers• Alternative: Let a participant P in the ready state
timeout when it hasn’t received the coordinator’s decision– P tries to find out what other participants know
• Question: Can P not succeed in getting the required information?
![Page 25: EEC-681/781 Distributed Computing Systems](https://reader035.vdocuments.us/reader035/viewer/2022062723/56813c20550346895da59664/html5/thumbnails/25.jpg)
2525
Fall Semester 2008Fall Semester 2008 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao
2PC 2PC –– Failing Coordinator Failing Coordinator• Question: Can P not succeed in getting the required
information? • Observation: Essence of the problem is that a
recovering participant cannot make a local decision: it is dependent on other (possibly failed) processes– There might exist one participant that has received a COMMIT
decision from the coordinator and subsequently failed (more or less concurrently failed with the coordinator)
– The rest of participants cannot unilaterally decide to abort the transaction