1. Transactions in Distributed Systems
4/24/2019

2. Distributed vs. Local Systems
Slower to access information from remote node.
Partial crashes in the system.
Problems with message transmissions.
Access of local information is much faster.
Total Crashes.
4/24/2019

3. What is a transaction?
In databases, a transaction is “a collection of operations that represent a unit of consistency and recovery”
Overall view of a transaction:
Initialization. (Memory, resources etc.)
Reads and modifications to consistent resource objects.
Abort: Changes are undone and not saved and resources are released
Commit: Changes are saved and resources are released. Resources and information remain consistent.
4/24/2019

4. Distributed Transactions
Problem and solution ideas are very similar to the ones in transactions of database systems.
Solutions such as Concurrency, Atomicity and Recovery of transactions.
Additional problems in distributed transactions due to the reliance on network communication.
4/24/2019

5. Problems with Distributed Transactions
Concurrency control of transactions
Inconsistencies due to Failures
Recovery from System Crashes
Presented solutions: Argus, QuickSilver, RVM
4/24/2019

6. Concurrency Solution
Use of read and write locks to synchronize the access or modification of system resources.
A two-phase lock mechanism to allow full seriability.
4/24/2019

7. Inconsistent system states due to Failures
This is solved having atomicity of operations.
An operation can either commit or abort.
4/24/2019

8. Solution to Recovery
Save useful data of a transaction in stable storage.
Have a mechanism to bring back the whole system to a consistent state before continuing the transaction or abort the transaction.
4/24/2019

9. Committing a transaction
Have mechanism to ensure that all operations, remote or local, commit or abort at “near” the same time when transaction commits.
Making sure that after transaction commit the entire system remains consistent.
4/24/2019

10. Argus -Barbara Liskov et al.
A programming language and System for Distributed Programs
Intended for programs that keep online data for long periods of time
Guardians provide nice encapsulation of objects and resources.
Actions allow atomicity of processes
4/24/2019

11. Assumptions Nodes can communicate only the exchange of messages.
It is impossible for a failed node to send messages.
Messages may be lost, delayed or out of order.
Corruption in messages are detectable.
4/24/2019

12. Guardians Object that encapsulates resources in the system.
Resides in a single node and each node can have more than one guardian.
Resources are accessed through handlers(location independent).
Guardians can create other Guardians at the specified node.
Contains stable objects and volatile objects.
4/24/2019

13. Printer Guardian
4/24/2019

14. Atomic Actions (Actions)
Actions are total, either it commits or aborts(using atomic objects).
Actions can be nested(actions & subactions).
When action commits it propagates its locks and the object versions of the local guardian to the parent action.
The p-list (participating guardians of committed descendents) propagate to the parent.
4/24/2019

15. Actions are Serializable
Strict two-phase locking is used(locks are held until action commits or aborts).
Can prove that using a strict two-phase lock mechanism implies seriability of actions.
4/24/2019

16. Action Tree
4/24/2019

17. Concurrency Control Solution
Synchronization access to resources is done via locks.
Every operation is a read or a write.
Seriability, totality and synchronization of actions to shared objects.
4/24/2019

18. Locks in Nested Transactions - J. Eliot B. Moss
“An action can acquire a read lock iff all holders of write locks are ancestors”
“It can acquire a write lock iff all holders of read or write locks are ancestors”
4/24/2019

19. Inconsistencies
Inconsistencies are solved via the totality of actions.
An action can either commit or abort.
4/24/2019

20. Recovery from Crashes
Solved by the atomicity of actions and by using versions of the stable objects.
Versions are passed up the action tree when action commits.
4/24/2019

21. Two-Phase Commit Protocol (I)
Topaction guardian sends “prepare” messages to guardian participants in the transaction.
Participants receive message, records versions of the objects modified by the descendents and a “prepare” record is saved in stable storage. Read locks are released.
Participants replies with an “ok” message.
If some participant can’t save the necessary information it sends a “refuse” message.
If topaction receives any refused response or does not respond, it aborts the transaction and “abort” messages are sent.
4/24/2019

22. Two-Phase Commit Protocol (II)
If every participant replies “ok”, topaction guardian writes a committed record and sends “commit” messages to participants.
Participant writes a commit record, updates new versions of the objects, releases locks and sends a “done” message.
Topaction guardian saves a record after all participants have acknowledge.
2Phase Commit Protocol makes sure that the transaction either commits or aborts.
4/24/2019

23. Data on Action Commits and Aborts
4/24/2019

24. Timing of Topactions
4/24/2019

25. QuickSilver -Schmuck & Wyllie
Operating system that supports atomicity, recoverability and concurrency of transactions.
Flexible Concurrency control policy, each node can have its own policy.
Transaction commit is done via one-phase or two-phase commit protocol depending on the node.
No nested transactions.
4/24/2019

26. Transaction Management
It is made up of three main pieces.
Transaction Manager.
Transactional IPC.
A log manager.
4/24/2019

27. Transaction Manager
Transaction Manager handles the coordination of a transaction, from start to finish.
TM starts a transaction when it receives an IPC request from a process.
TM assigns globally unique TID and registers it with the kernel.
4/24/2019

28. Transactional IPC IPC are done on behalf of a transaction.
A participant of a transaction is either a process that created the transaction or a process that received a request with an TID.
Remote requests are handled by the local Communication Manager process (CM).
4/24/2019

29. Log Manager Records appended at the end of a file.
Uses log to recover during the two-phase commit protocol.
LM may be used as checkpoints in long running computations.
4/24/2019

30. Concurrency
QuickSilver allows each node to have it’s own concurrency control policy.
DFS does not enforce full seriability(improves performance).
Write locks obtained only when directory is renamed, created or deleted.
Reads lock are not required when reading a directory.
Read locks on files are released when file is closed.
Write locks on files are released until transaction commits.
4/24/2019

31. Recovery
Recovery is handled by the QuickSilver distributed file system (DFS).
Guarantees changes are saved on commit and it undoes any changes on abort.
4/24/2019

32. Transaction Commit
TM collects information about all the participants from the kernel.
If CM is a participant, TM asks for list of machines who received a request.
TM requests all remote machines to recursively commit.
Any communication or machine failures detected by CM causes an abort in the transaction.
4/24/2019

33. Comparing AIX and QuickSilver
4/24/2019

34. Recoverable Virtual Memory Satyanarayanan et al.
Only addresses the problem of Recovery.
Stores Virtual memory in external data segments found in stable storage.
Portable with a library that is linked in with applications.
“Value simplicity over generality” by adopting a layered approach.
Provides independent control over atomicity and concurrency as well as other problems such as deadlocks and starvations.
4/24/2019

35. Layered Approach of RVM
4/24/2019

36. Segments and Regions
Applications map regions of segments into their virtual memory.
4/24/2019

37. Sequence of Operations
Select regions in virtual memory to be mapped.
Get a global transaction ID.
Successful commit saves segments in log.
4/24/2019

38. Crash Recovery
Recovery consists of reading the log from tail to head and then reconstructing the last committed changes.
Modifications are applied to the external data segment.
Log is emptied.
4/24/2019

39. Truncation
Reclaiming space in the log by applying changes to the external data segment.
Necessary because space is finite.
4/24/2019

40. In Summary
Argus provides a complete solution with atomicity, concurrency control and recovery.
However, it is too complex, slow and unoptimized.
QuickSilver shifts the problem of concurrency control to the individual nodes and performs as good as AIX.
RVM addresses only the problem of recovery in VM and introduces a “neat” layered structure to address the other problems.
4/24/2019