Distributed Object Transactions

1. Distributed Object Transactions • Transaction principles • Concurrency control • The two-phase commit protocol • Services for distributed object transactions 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. Distributed Object Transactions

3. Transaction Operations • Begin/commit • Flat transactions • Simple to implement • Potential loss of all previous transactions • Nested transactions • Flexible • Difficult to implement Distributed Object Transactions

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 serializable if the same result can e achieved by executing them in sequential order Distributed Object Transactions

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 Distributed Object Transactions

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 Distributed Object Transactions

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 Distributed Object Transactions

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 Distributed Object Transactions

9. Hierarchical Locking Example • T1 produces a sum of the balances of a particular customer, whose accounts are managed at branch B1; • T2 performs a funds transfer between two accounts held at branch B1; • 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 … Distributed Object Transactions

10. Hierarchical Locking Example Distributed Object Transactions

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 Distributed Object Transactions

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 3*N messages • Uncertainty of the servers • What if the server crash after it voted for ‘commit’? • Store state information on persistent temporary storage for recovery Distributed Object Transactions

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. Distributed Object Transactions