<?xml version="1.0"?>
<!--
  JBoss, Home of Professional Open Source
  Copyright 2006, Red Hat Middleware LLC, and individual contributors
  as indicated by the @author tags.
  See the copyright.txt in the distribution for a full listing
  of individual contributors.
  This copyrighted material is made available to anyone wishing to use,
  modify, copy, or redistribute it subject to the terms and conditions
  of the GNU Lesser General Public License, v. 2.1.
  This program is distributed in the hope that it will be useful, but WITHOUT A
  WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
  PARTICULAR PURPOSE.  See the GNU Lesser General Public License for more details.
  You should have received a copy of the GNU Lesser General Public License,
  v.2.1 along with this distribution; if not, write to the Free Software
  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
  MA  02110-1301, USA.


  (C) 2005-2006,
  @author JBoss Inc.
-->
<page title="JBossTS Trail map: Overview of the Distributed Transaction Processing" rootpath="../..">
	<header>
        Trail map: Overview of the Distributed Transaction Processing
        </header>
	<content>
		<navigation>
			<links include="includes/www_arjuna_com_navigation.xml"/>
			<links include="includes/trailmap_navigation.xml"/>
			<links title="Navigation">
				<link ref="index.html">Home</link>
			</links>
			<links include="includes/trailmap_additional.xml"/>
		</navigation>
		<area title="Overview of the Distributed Transaction Processing">
			<html>
				<h4>What is a Transaction</h4>
				<p>Transaction management is one of the most crucial requirements for enterprise application development. Most of the large enterprise applications
  	in the domains of finance, banking and electronic commerce rely on transaction processing for delivering their business functionality. </p>
				<p>Enterprise applications often require concurrent access to distributed data  shared amongst multiple components, to perform operations on data. Such
  applications should maintain integrity of data (as defined by the business  rules of the application) under the following circumstances: </p>
				<ul>
					<li>distributed access to a single resource of data, and </li>
					<li>access to distributed resources from a single application component.
   	 </li>
				</ul>
				<p>In such cases, it may be required that a group of operations on (distributed) resources be treated as one unit of work. In a unit of work, all
	  the participating operations should either succeed or fail and recover together. This problem is more complicated when </p>
				<ul>
					<li>a unit of work is implemented across a group of distributed components operating on data from multiple resources, and/or </li>
					<li>the participating operations are executed sequentially or in parallel  threads requiring coordination and/or synchronization. </li>
				</ul>
				<p>In either case, it is required that success or failure of a unit of work be maintained by the application. In case of a failure, all the resources should
 	 bring back the state of the data to the previous state (<i>i.e.,</i> the state prior to the commencement of the unit of work). </p>
				<p> From the programmer's perspective a transaction is a scoping mechanism for a collection of actions which must complete as a unit. It provides a
    simplified model for exception handling since only two outcomes are possible: </p>
				<ul>
					<li> success - meaning that all actions involved within a transaction are completed </li>
					<li> 	failure - no actions complete 	</li>
				</ul>
				<img src="includes/trans_succes_failure.GIF"/>
				<h5>Example</h5>
				<br>
			  		 To illustrate the reliability expected by the application let’s consider  the funds transfer example which is familiar to all of us.
					</br>

      The Money transfer involves two operations: Deposit and Withdrawal

				<br>
					The complexity of implementation doesn't matter; money moves from one place to
      another. For instance, involved accounts may be either located in a same relational table within
      a database or  located on different databases.
				</br>
				<br>
					A Simple transfer consists on moving money from savings to checking while a Complex transfer can be performed at the end- of- day according
      to a reconciliation between international banks </br>
				<img border="0" src="includes/example_transfer.GIF"/>
				<a name="Introduction">
					<a name="What is a Transaction"/>
					<p>The concept of a transaction, and a transaction manager (or a transaction
  processing service) simplifies construction of such enterprise level
  distributed applications while maintaining integrity of data in a unit of
  work. </p>
				</a>
				<p>A transaction is a unit of work that has the following properties: </p>
				<ul>
					<li>
						<strong>Atomicity</strong> – either the whole transaction completes or
    nothing completes - partial completion is not permitted. </li>
					<li>
						<strong>Consistency</strong> – a transaction transforms the system from
    one consistent state to another. In other words, On completion of a
    successful transaction, the data should be in a consistent state. For
    example, in the case of relational databases, a consistent transaction
    should preserve all the integrity constraints defined on the data. </li>
					<li>
						<b>Isolation:</b> Each transaction should appear to execute
    independently of other transactions that may be executing concurrently in
    the same environment. The effect of executing a set of transactions serially
    should be the same as that of running them concurrently. This requires two
    things:
    <ul>
							<li>During the course of a transaction, intermediate (possibly
      inconsistent) state of the data should not be exposed to all other
      transactions. </li>
							<li>Two concurrent transactions should not be able to operate on the same
      data. Database management systems usually implement this feature using
      locking. </li>
						</ul>
					</li>
					<li>
						<b>Durabiliy:</b> The effects of a completed transaction should always
    be persistent. </li>
				</ul>
				<p>These properties, called as <b>ACID</b> properties, guarantee that a
  transaction is never incomplete, the data is never inconsistent, concurrent
  transactions are independent, and the effects of a transaction are persistent.
  </p>
				<h4>Transactional Concepts</h4>
				<h5>Transaction Components</h5>
				<p>A collection of actions is said to be transactional if they possess the ACID properties. These properties
are assumed to be ensured, in the presence of failures; if actions involved within the transaction
are performed by a Transactional System. A transaction system includes a set of components where each of
them has a particular role. Main components are described below. </p>
				<div style="mso-line-spacing:&quot;100 30 0&quot;;mso-char-wrap:1;mso-kinsoku-overflow:1">
					<img border="0" src="includes/transaction_components.GIF"/>
					<h5>
						<span style="font-family: Times New Roman" lang="en-gb">Application
      Programs</span>
					</h5>
					<p>Application Programs are clients for the transactional resources. These
      are the programs with which the application developer implements business
      transactions. With the help of the transaction manager, these components
      create global transactions and operate on the transactional resources with
      in the scope of these transactions. These components are not responsible
      for implementing mechanisms for preserving ACID properties of
      transactions. However, as part of the application logic, these components
      generally make a decision whether to commit or rollback transactions.</p>
					<p>Application responsibilities could be summarized as follow:</p>
					<ul>
						<li>Create and demarcate transactions </li>
						<li>Operate on data via resource managers</li>
					</ul>
					<h5>
						<span style="font-family: Times New Roman" lang="en-gb">Resource
      Managers</span>
					</h5>
					<p>A resource manager is in general a component that manages persistent
      and stable data storage system, and participates in the two phase commit
      and recovery protocols with the transaction manager. </p>
					<p>A resource manager is typically a driver that provides two
      sets of interfaces: one set for the application components to get
      connections and operating, and the other set for participating in two
      phase commit and recovery protocols coordinated by a transaction manager.
      This component may also, directly or indirectly, register resources with
      the transaction manager so that the transaction manager can keep track of
      all the resources participating in a transaction. This process is called
      as resource enlistment. </p>
					<p>Resource Manager responsibilities could be summarized as follow</p>
					<ul>
						<li>Enlist resources with the transaction manager </li>
						<li>Participate in two-phase commit and recovery protocol </li>
					</ul>
					<h5>
						<span lang="en-gb">
							<font face="Times New Roman">Transaction Manager</font>
						</span>
					</h5>
					<p>The transaction manager is the core component of a transaction
      processing environment. Its main responsibilities are to create
      transactions when requested by application components, allow resource
      enlistment and delistment, and to manage the two-phase commit or recovery
      protocol with the resource managers. </p>
					<p>A typical transactional application begins a transaction by issuing a
      request to a transaction manager to initiate a transaction. In response,
      the transaction manager starts a transaction and associates it with the
      calling thread. The transaction manager also establishes a transaction
      context. All application components and/or threads participating in the
      transaction share the transaction context. The thread that initially
      issued the request for beginning the transaction, or, if the transaction
      manager allows, any other thread may eventually terminate the transaction
      by issuing a commit or rollback request. </p>
					<p>Before a transaction is terminated, any number of components and/or
      threads may perform transactional operations on any number of
      transactional resources known to the transaction manager. If allowed by
      the transaction manager, a transaction may be suspended or resumed before
      finally completing the transaction. </p>
					<p>Once the application issues the commit request, the transaction manager
      prepares all the resources for a commit operation, and based on whether
      all resources are ready for a commit or not, issues a commit or rollback
      request to all the resources.</p>
					<p>Resource Manager responsibilities could be summarized as follow:</p>
					<ul>
						<li>Establish and maintain transaction context </li>
						<li>Maintain association between a transaction and the participating
        resources. </li>
						<li>Initiate and conduct two-phase commit and recovery protocol with the
        resource managers. </li>
						<li>Make synchronization calls to the application components before
        beginning and after end of the two-phase commit and recovery process
        </li>
					</ul>
				</div>
				<h5>Local vs. Distributed Transaction</h5>
				<p>
					 A transaction that involves only one transactional resource, such a database,
  is considered as <i>local transaction</i>, while a transaction that involves
  more than one transactional resource that need to be coordinated to reach a
  consistent state is considered as a <i>distributed transaction.</i>
				</p>
				<p>A transaction can be specified by what is known as transaction demarcation.
  Transaction demarcation enables work done by distributed components to be
  bound by a global transaction. It is a way of marking groups of operations to
  constitute a transaction. </p>
				<p>The most common approach to demarcation is to mark the thread executing the
  operations for transaction processing. This is called as programmatic
  demarcation. The transaction so established can be suspended by unmarking the
  thread, and be resumed later by explicitly propagating the transaction context
  from the point of suspension to the point of resumption. </p>
				<p>The transaction demarcation ends after a commit or a rollback request to
  the transaction manager. The commit request directs all the participating
  resources managers to record the effects of the operations of the transaction
  permanently. The rollback request makes the resource managers undo the effects
  of all operations on the transaction. </p>
				<h5>Transaction Context and Propagation </h5>
				<p>Since multiple application components and resources participate in a
  transaction, it is necessary for the transaction manager to establish and
  maintain the state of the transaction as it occurs. This is usually done in
  the form of transaction context. </p>
				<p>Transaction context is an association between the transactional operations
  on the resources, and the components invoking the operations. During the
  course of a transaction, all the threads participating in the transaction
  share the transaction context. Thus the transaction context logically envelops
  all the operations performed on transactional resources during a transaction.
  The transaction context is usually maintained transparently by the underlying
  transaction manager. </p>
				<h5>Resource Enlistment</h5>
				<p>Resource enlistment is the process by which resource managers inform the
  transaction manager of their participation in a transaction. This process
  enables the transaction manager to keep track of all the resources
  participating in a transaction. The transaction manager uses this information
  to coordinate transactional work performed by the resource managers and to
  drive two-phase and recovery protocol. At the end of a transaction (after a
  commit or rollback) the transaction manager delists the resources. </p>
				<h5>
					<a name="2pc"/>Two-Phase Commit</h5>
				<p>This protocol between the transaction manager and all the resources
  enlisted for a transaction ensures that either all the resource managers
  commit the transaction or they all abort. In this protocol, when the
  application requests for committing the transaction, the transaction manager
  issues a prepare request to all the resource managers involved. Each of these
  resources may in turn send a reply indicating whether it is ready for commit
  or not. Only The transaction manager issue a commit request to all the
  resource managers, only when all the resource managers are ready for a commit.
  Otherwise, the transaction manager issues a rollback request and the
  transaction will be rolled back. </p>
				<h5>
					<a name="RecoveryLog"/>Recovery and Logging</h5>
				<div>
	Basically, the Recovery is the mechanism which preserves the transaction atomicity in presence of failures.
	The basic technique for implementing transactions in presence of failures is based on the use of logs. That  is, a transaction system has to record enough information to ensure that
      it can be able to return to a previous state in case of failure or to  ensure that changes committed by a transaction are properly stored.
					<p>
      In addition to be able to store appropriate information, all participants within a distributed transaction must log similar information which allow
      them to take a same decision either to set data in their final state or in  their initial state. </p>
					<p>		Two  techniques are in general  used to ensure transaction's atomicity. A  first technique  focuses on manipulated data, such the  Do/Undo/Redo protocol
	 (considered as a recovery mechanism in a centralized system), which allow a participant to set its data in their final values or to
      retrieve them in their initial values. A second technique relies on a distributed protocol named the two phases commit,
      ensuring that all participants involved within a distributed transaction  set their data either in their final values or in their initial values.
      In other words all participants must commit or all must rollback. </p>
					<img border="0" src="includes/recovery_logs.GIF"/>
					<p/>
					<p>
          In addition to failures we refer as centralized such system crashes,
          communication failures due for instance to <span style="mso-spacerun:yes"/>network outages or message loss have to be considered during
          the recovery process of a distributed transaction.
							</p>
					<p>
          In order to provide an efficient and optimized mechanism to deal with
          failure, modern transactional systems typically adopt a “presume
          abort” strategy, which simplifies the transaction management.
          						</p>
					<p>
          The presumed abort strategy can be stated as «when in doubt, abort».
          With this strategy, when the recovery mechanism has no information
          about the transaction, it presumes that the transaction has been
          aborted. </p>

          A particularity of the presumed-abort assumption allows a coordinator
          to not log anything before the commit decision and the participants do
          not to log anything before they prepare. Then, any failure which
          occurs before the 2pc starts lead to abort the transaction.
          Furthermore, from a coordinator point of view any communication
          failure detected by a timeout or exception raised on sending prepare
          is considered as a negative vote which leads to abort the transaction.


          So, within a distributed transaction a coordinator or a participant
          may fail in two ways: either it crashes or it times out for a message
          it was expecting. When a coordinator or a participant crashes and
          then restarts, it uses information on stable storage to determine the
          way to perform the recovery. As we will see it the presumed-abort
          strategy enable an optimized behavior for the recovery.
						</div>
				<h5>Heuristic Decision</h5>

          In extremely rare cases, a resource manager may choose not to wait for
          the outcome from the transaction manager. This might occur if the
          communications path was lost and was not likely to be restored for a
          very long time. Typically this
          happens as a result of human intervention and not as an arbitrary
          action of a resource manager.

          In order to release locks and make this transactions data available to
          new transactions, the resource manager makes a <b>heuristic decision</b>,
          i.e. it guesses the proper transaction outcome. When it does so, it
          must remember its guess until contact with the transaction manager is
          ultimately re-established.

					<h4>Standards</h4>
					      Saying that a distributed transaction can involve several distributed
      participants, means that these participant must be integrated within a
      global transaction manager which has the responsibility to ensure that all
      participants take a common decision to commit or rollback the distributed
      transaction. The key of such integration is the existence of a common
      transactional interface which is understood by all participants,
      transaction manager and resource managers such databases.
					<p>
      The importance of common interfaces between participants, as well as the
      complexity of their implementation, becomes obvious in an open systems
      environment. For this aim various distributed transaction processing
      standards have been developed by international standards organizations.
      Among these organizations, We list three of them which are mainly
      considered in the JBoss Transaction Service product: </p>
				<ul>
					<li>
							 The <a class="linkscoloured" href="xopen_overview.html">X/Open model </a> and its successful XA interface
						</li>
					<li>
							     The OMG with its CORBA infrastructure and the  <a class="linkscoloured" href="ots_overview.html">Object
        Transaction Service</a> and finally
						</li>
					<li>
							        The Java Community Process leaded by Sun with its <a class="linkscoloured" href="JTA_overview.html">
        JTA/JTS specification</a>
					</li>
				</ul>
					      Basically these standards have proposed logical models, which divide
      transaction processing into several functions:
					<ul>
					<li>
							 those assigned to the application which ties resources together in application- specific operations
							</li>
					<li>
							those assigned to the  Resource manager which access physically to data stores
						</li>
					<li>
							functions performed by the Transaction Manager which manages  transactions, and finally
						</li>
					<li>
							Communication Resource Managers which allow to exchange information with other transactional domains.
						</li>
				</ul>
				<img border="0" src="includes/standards.GIF"/>
			</html>
		</area>
	</content>
	<footer/>
</page>
