Distributed Object Transactions

1
Distributed Object Transactions

• Transaction principles
• Concurrency control
• The two-phase commit protocol
• Services for distributed object transactions

2
Transaction Principles

• Transaction cluster several object requests into
  a coarse-grained unit
• Transaction is either performed completely or not
  at all
• Transaction leaves objects in a consistent state
• Transaction is performed in isolation from any
  concurrent transaction
• Once completed, the result of the transaction is
  prevented from being lost
• In other words, transaction is an atomic,
  consistent, isolated and durable sequence of
  operations (ACID).
• Execution semantics of transactions cannot be
  defined for single operations.

3
Transaction Operations

• Begin/commit
• Flat transactions
• Simple to implement
• Potential loss of all previous transactions
• Nested transactions
• Flexible
• Difficult to implement

4
Concurrency Control

• Concurrency control is transparent to client
  designers, but may not be transparent to server
  designers
• Using relational, oo database to store info
• Using file to store info
• Concurrency anomaly
• Lost updates modifications done in one thread
  that are overwritten by another
• Inconsistent analysis object is modified
  concurrently while the analysis is performed
  (read and write)
• Serializability
• Transactions are serialiable if the same result
  can e achieved by executing them in sequential
  order

5
Two-Phase Locking

• Concurrency control technique
• Guarantee serializability
• Consists of a lock acquisition and a lock release
  phase
• Locks
• Binary locks on a resource can either be held or
  not held ? too restrictive
• Lock modes determine operations that transactions
  can request from objects (read lock, write lock)
• Lock compatibility matrices determine
  compatibility and conflicts between locking modes
• Read write
• Read Y N
• Write N N

6
Deadlocks

• Concurrency properties
• Liveness something desirable will eventually
  happen
• Safety bad thing will never happen
• Faireness each thread will eventually get its
  turn to make progress
• Starvation some thread gets deferred forever
• Deadlock threads/transactions are waiting for
  each other to release locks
• Two-phase locking is not deadlock free

7
Deadlock Detection

• Transaction waiting graphs
• Node transactions
• Edge wait-for relationship between
  transaction
• Deadlock iff there is a cycle in the graph
• Complexity of deadlock detection algorithm is
  linear with respective to the number of nodes
  (transactions)
• Break the deadlock by aborting involved
  transactions
• Choose the one with max in/out edges

8
Hierarchical Locking

• 2PL is inefficient if transactions need large
  number of objects
• Locking granularity
• Hierarchical locking protocol
• Hierarchical locking protocols lock all component
  objects with one locking operation applied to the
  composite object
• Intention lock
• A lock acquired for a composite object before a
  transaction requests a real lock for an object
  that is contained in the composite object.
• It signals to other transactions that with to
  lock the entire composite object that some other
  transaction currently has locks for objects that
  are contained in the composite object.
• Intention locks have modes
• Intention Read Read Intention Write Write
• Intention Read Y Y Y N
• Read Y Y N N
• Intention Write Y N Y N
• Write N N N N
• Hierarchical locking protocols locks every
  composite object of a component object

9
Hierarchical Locking Example

1. T1 produces a sum of the balances of a particular
   customer, whose accounts are managed at branch
   B1
2. T2 performs a funds transfer between two accounts
   held at branch B1
3. T3 produces a sum of the balances of all accounts
   held at a group of branches to which B1 belongs

Bank
Gm

G1
B1
Bn


10
Hierarchical Locking Example
Bank G1 B1 Ai, Aj, Ak
T1
T2
T3
Bank G1 B1 Ai, Aj, Ak
T1 IR IR IR R
T2 IW IW IW W,W
T3 IR R R R
11
CORBA Concurrency Control Service

• Adopted in 1994
• Support hierarchical 2PL
• Compatibility
• Upgrade locks are used when initially needs read
  access to an object, but already knows it will at
  a alter point need to acquire a write lock for
  the object

IR R Upgrade IW W
IR -
R - -
Upgrade - - -
IW - - -
W - - - - -
12
Two-Phase Commit for Flat Transactions

• Distributed transaction commits can only be done
  in two phase
• Transaction coordinator
• Voting phase servers decide whether they can
  commit
• Completion phase servers perform commit
• Transaction implementation is transparent to
  client, not to the server
• Overhead of processing distributed transactions
• N servers participate in a transaction
• Every server needs to register to transaction
  coordinator, N messages
• N voting messages from the servers
• N docommit messages to the servers
• Total 3N messages
• Uncertainty of the servers
• What if the server crash after it voted for
  commit?
• Store state information on persistent temporary
  storage for recovery

13
Recovery

• Failure prior to commit
• Fail before requesting the commit message,
  transaction coordinator abort the transaction
• Failure of server before voting
• Absence of a vote from a server vote against a
  commit
• Failure of coordiantor during voting
• Coordinator fails before or during the vote, ?
  abort
• Failure of server after voting
• If voted for commit before the server fails, it
  will ask the coordinator about the commit
  decision and do the commit if the decision is
  commit
• Failure of coordinator after first doCommit
• Use the data it store on temporary persistent
  storage and re-transmit the docommit requests
  to the rest of the participating servers.