Transactions in Distributed Systems

1
Transactions in Distributed Systems
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.

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

5
Problems with Distributed Transactions

• Concurrency control of transactions
• Inconsistencies due to Failures
• Recovery from System Crashes
• Presented solutions Argus, QuickSilver, RVM

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.

7
Inconsistent system states due to Failures

• This is solved having atomicity of operations.
• An operation can either commit or abort.

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.

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.

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

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.

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.

13
Printer Guardian
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.

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.

16
Action Tree
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.

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

19
Inconsistencies

• Inconsistencies are solved via the totality of
  actions.
• An action can either commit or abort.

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.

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 cant 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.

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.

23
Data on Action Commits and Aborts
24
Timing of Topactions
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.

26
Transaction Management

• It is made up of three main pieces.
• Transaction Manager.
• Transactional IPC.
• A log manager.

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.

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).

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.

30
Concurrency

• QuickSilver allows each node to have its 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.

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.

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.

33
Comparing AIX and QuickSilver
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.

35
Layered Approach of RVM
36
Segments and Regions

• Applications map regions of segments into their
  virtual memory.

37
Sequence of Operations

• Select regions in virtual memory to be mapped.
• Get a global transaction ID.
• Successful commit saves segments in log.

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.

39
Truncation

• Reclaiming space in the log by applying changes
  to the external data segment.
• Necessary because space is finite.

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.