Docstoc

dtm02-07

Document Sample
dtm02-07 Powered By Docstoc
					Distributed Transaction Management, Fall 2002




       Unconventional transactions


                     Jyrki Nummenmaa
                 http://www.cs.uta.fi/~jyrki/
                        jyrki@cs.uta.fi
Distributed Transaction Management, Fall 2002




                               Motivation
 Transactions managing design data can
  be very long, as the design progresses
  slowly.
 Business transactions may progress
  slowly, as they may involve exchange of
  electronic documents between
  companies.
Distributed Transaction Management, Fall 2002




      Traditional TP for long txns?
   Traditional transaction processing may not
    be appropriate, as
        items may get locked for too long,
        global commit or rollback may not be feasible,
         and
        global recovery may not be feasible
Distributed Transaction Management, Fall 2002




            Hierarchical transactions
   One approach to solving these problems
    is to divide the transactions into parts
    hierarchically.
        Each part will be committed separately.
        The hierarhical division is, of course,
         fundamentally different from just distribution.
        The transactions in the hierarchy may be
         distributed or centralised.
Distributed Transaction Management, Fall 2002




  Hierarchical transaction commit
   Principle: a transaction in the hierarchy can be
    committed, when all of its sub-parts have been
    committed.
   Sub-parts are committed as their work is done.
   This way, locking will be less problematic, as
    locks are released as part-transactions commit.
Distributed Transaction Management, Fall 2002




                  Problematic rollback
 If all goes well (all transactions in the
  hierarhcy commit)
 What happens, if there is a need to
  rollback, and some part-transactions
  have already been committed?
 We need some way to manage with the
  already committed part-transactions.
Distributed Transaction Management, Fall 2002




    Simple rollback is not possible
 Suppose that one part-transaction in the
  hierarchy needs to rollback, while some
  other part-transaction has already
  committed.
 Simple rollback does not necessarily do,
  as committed transactions may have
  some side-effects.
Distributed Transaction Management, Fall 2002




     Restarting the part-transaction
 If it is possible to re-start the initially
  failed part-transaction, then the problem
  of rolling back the already committed
  disappears.
 This may not be always possible, but
  should, of course, be done whenever
  possible.
Distributed Transaction Management, Fall 2002




         Compensating transactions
 One possibility to roll back an already
  committed (part-)transaction is to use a
  compensating transaction.
 A compensating transaction somehow
  negates the effects of the original
  transaction.
Distributed Transaction Management, Fall 2002




      What cannot be compensated
   Examples:
        money given from a cashline machine
        a money transfer to a bank account
        an access given and already used
        an electronic document/program
         downloaded or sent
Distributed Transaction Management, Fall 2002



          The previous slide was not
                exactly true...
 Although the compensation can not be
  done automatically, there may be ways to
  do it through electronic or manual
  document or message exhange.
 This is particularly true for business-to-
  business transactions between trusted
  partners.
Distributed Transaction Management, Fall 2002




            Alternative continuations
 In some application fields it may be
  possible to continue the transaction in
  some other way, if the first way does not
  work out, without having to roll back the
  all or some parts of the transaction.
 If some part of a business transaction
  leads to failure, there may be another
  equally possible way to do it.
Distributed Transaction Management, Fall 2002



    Technology for distributed txn
            management
 Java2EE and Microsoft have their own
  technologies available for middleware
  implementation.
 You can use an API to make a participant
  and use the coordinator provided by
  J2EE/Microsoft.
 TIP is yet another possibility – but has
  not been a success.
Distributed Transaction Management, Fall 2002




             Why this is not enough?
 These technologies do not support the
  hierarchical transaction management.
 The companies like to have the control
  over their transactions.
 TIP supports heterogeneous
  environments, but is vulnerable to failure
  and attacks.
Distributed Transaction Management, Fall 2002



    Problems to solve with TIP-like
               solutions
 Security
 Trust
 Denial-of-service attacks
 Recovery, when the protocol fouls up.
Distributed Transaction Management, Fall 2002




     TIP – denial of service attacks
   PULL-based:
        A rogue company that knows the transaction ID
         sends a PULL to a site then close the connection.
   PUSH-based
        Flood a sites with PUSHes so that it cannot service
         legitimate requests.
   If a site loses its connection to its superior, the
    rogue sites sends it a RECONNECT command
    and tells it the wrong result of the commit.
Distributed Transaction Management, Fall 2002




                      TIP – repudiation
   Interaction of 2PC and authenticated protocol
    messages
        The semantics of the authenticated messages only
         apply if the txn is committed.
   If a message from A to B is part of a 2PC
    protocol, then B’s possession of the digital
    signature proves nothing.
        A can claim: Yes, that was sent, but the action was
         rolled back.
        B must prove that the action was committed. B must
         also prove that the message was part of that txn.
Distributed Transaction Management, Fall 2002



    Problems to solve with TIP-like
          solutions : security
   It is possible to use Secure-
    HTTP/SSL/TLS with
        encryption and
        end-to-end authentication
   This works for just security, but
    developments for trust and denial-of-
    service attack management will probably
    require changes here.
Distributed Transaction Management, Fall 2002



    Problems to solve with TIP-like
           solutions : trust
   If just about any company may participate in
    the transactions, then trust for the good will of
    the company is required. This, in particular has
    to do with denial-of-service attacks and non-
    repudiation.
   Even if participation is limited to companies,
    whose good will we trust, we still need to trust
    their implementations.
Distributed Transaction Management, Fall 2002



    Problems to solve with TIP-like
     solutions : ”manual” recovery
 If the protocol fails and manual recover is
  necessary, then how will this be done in
  inter-company transactions?
 In other words, operator intervention is
  needed when the commit protocol fouls
  up - how will this work on the Internet?
Distributed Transaction Management, Fall 2002



              Brokerage companies /
              electronic marketplaces
 It would seem from above that there is
  demand for electronic marketplaces or
  brokerage companies through which
  business is done.
 Some such marketplaces have been
  implemented – they have been
  expensive and there is no evidence as
  yet that they will meet the expectations.
Distributed Transaction Management, Fall 2002




                            Current trend
 Companies write their complicated
  business transactions in a way in which
  they manage their own transactions
  themselves instead of giving the control
  outside.
 This means that in case of troublesome
  rollback situations, they have to use
  compensating – but not necessarily
  100% automatic – transactions.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:2/14/2012
language:
pages:22