<?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>
				<link ref="part1.html">Previous</link>
				<link ref="part3.html">Next</link>
			</links>
		</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>Durability:</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>
