Distributed object transactions
This presentation is the property of its rightful owner.
Sponsored Links
1 / 13

Distributed Object Transactions PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Distributed Object Transactions. Transaction principles Concurrency control The two-phase commit protocol Services for distributed object transactions. Transaction Principles. Transaction cluster several object requests into a coarse-grained unit

Download Presentation

Distributed Object Transactions

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Distributed object transactions

Distributed Object Transactions

  • Transaction principles

  • Concurrency control

  • The two-phase commit protocol

  • Services for distributed object transactions

Distributed Object Transactions

Transaction principles

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

Transaction operations

Transaction Operations

  • Begin/commit

  • Flat transactions

    • Simple to implement

    • Potential loss of all previous transactions

  • Nested transactions

    • Flexible

    • Difficult to implement

Distributed Object Transactions

Concurrency control

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

Two phase locking

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




Distributed Object Transactions



  • 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

Deadlock detection

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

Hierarchical locking

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 ReadReadIntention WriteWrite

        Intention ReadYYYN


        Intention WriteYNYN


    • Hierarchical locking protocols locks every composite object of a component object

Distributed Object Transactions

Hierarchical locking example

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






Distributed Object Transactions

Hierarchical locking example1

Hierarchical Locking Example

Distributed Object Transactions

Corba concurrency control service

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

Two phase commit for flat transactions

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



  • 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

  • Login