Download Document

Java Transactions Service
Presented by:
Dina Sarhan
Rana El Hattab
The Java Transaction Service
 The Java Transaction Service is a key element of the J2EE
architecture. Together with the Java Transaction API, it
enables us to build distributed applications that are robust to
all sorts of system and network failures.
 If you look at any source on J2EE, you'll find that only a
small part of the material discusses the both Java
Transaction Service (JTS) and the Java Transaction API
(JTA). This does not undermine the importance of JTS as
JTS gets less press than EJB technology because the
services it provides to the application are largely transparent
many developers are not even aware of where transactions
begin and end in their application.
What is a Transaction?
 What is an application's state?
 A transaction can be defined as a related collection
of operations on the application state.
 In other words, a transaction is a unit of work done by
multiple distributed components on shared data.
 A transaction has certain properties that are collectively
referred to as ACID properties.
ACID Properties of Transaction
 Atomicity-all changes that a transaction makes to a
database are made permanent; otherwise, all changes
are rolled back.
 Consistency-a successful transaction transforms a
database from a previous valid state to a new valid
state.
 Isolation-changes that a transaction makes to a
database are not visible to other operations until the
transaction completes its work.
 Durability-changes that a transaction makes to a
database survive future system or media failures.
Uses of Transactions
 Java Transactions is one of the most crucial requirements
for enterprise application development in the domains of
finance, banking and electronic commerce.
 Online Document Processing
 Regional Inventory Management Systems
 In general, any application that involves sharing data
among multiple distributed components.
Older Transaction Technologies
 X/Open Distributed Transaction
Processing Model
 Application Programs : implement
transactional operations.
 Resource Managers
 Transaction Managers
 Communication Resource
Manager which facilitate
interoperability between the different
transaction managers in different
transaction processing domains.
Some of the Interfaces
implemented
 TX Interface
 XA Interface :This interface is used to
support global transactions across different
transaction manager domains via
communication resource managers.
 TXRPC Interface :interface provides
portability for communication between
application programs within a global
transaction.
OMG Object Transaction Service
 The OTS model is based on the
X/Open DTP model with the following
enhancements:
 The OTS model replaces the
functional XA and TX interfaces with
CORBA IDL interfaces.
 The OTS is interoperable with
X/Open DTP model.
OMG Object Transaction Service
 Transaction Client
 Transactional Object:A CORBA object
that encapsulates or refers to persistent
data, and whose behavior depends on
whether or not its operations are invoked
during a transaction.
 Recoverable Object:A transactional object
that directly maintains persistent data, and
participates in transaction protocols
 Transactional Server
 Recoverable Server
 Resource Object
Additional features of the
CORBA OTS
 Nested Transactions:
This allows an
application to create a transaction that is
embedded in an existing transaction. In this
model, multiple subtransactions can be
embedded recursively in a transaction.
 The main advantage of this model is that the
application will have an opportunity to correct
or compensate for failures at the
subtransaction level, without actually
attempting to commit the complete parent
transaction.
 Application Synchronization: Using
the OTS synchronization protocol, certain
objects can be registered with the transaction
service for notification before the start of and
the completion of the two-phase commit
process. This enables such application objects
to synchronize transient state and data stored
in persistent storage.
Java Transaction Initiative - Architecture
 The Java transaction initiative consists of two
specifications: Java Transaction Service (JTS) and Java
Transaction API (JTA).
 JTS specifies the implementation of a Java transaction
manager.
 The JTA specifies an architecture for building
transactional application servers and defines a set of
interfaces for various components of this architecture.
Java Transaction Initiative - Architecture
Application
Server
Resource
manager
JTA
JTS
Java Transaction Service (JTS) architecture:
 The Java Transaction Service is architected around an
application server and a transaction manager as shown
in the next slide and consists of:
 Transaction Manager: The transaction manager is the
core component of this architecture and is provided by
an implementation of the JTS.
 Application Server: The application server abstracts all
transactional semantics from the application programs.
Java Transaction Service (JTS) architecture:
 Application Components: These are the clients for the
transactional resources that implement business
transactions and are deployed on the application server.
Depending on the architecture of the application server,
these components can directly or indirectly create
transactions and operate on the transactional resources.
 Resource Manager: A resource manager is an X/Open
XA compliant component that manages a persistent and
stable storage system.
 Communication Resource Manager: allows the
transaction manager to participate in transactions
initiated by other transaction managers.
Java Transaction Service (JTS) architecture:
Some Useful Examples:
 If:
 The client application needs to make invocations on
several objects, which may involve write operations
to one or more databases.
 The client application needs a conversation with an
object managed by the server application, and the
client application needs to make multiple invocations
on a specific object instance.
 Within the scope of a single client invocation on an
object, the object performs multiple edits to data in a
database. If one of the edits fails, the object needs a
mechanism to roll back all the edits.
Java Transaction API
(JTA)
Packages : javax.transaction
 Provides the API that defines the contract
between the transaction manager and the
various parties involved in a distributed
transaction ex : resource manager,
application, and application server.
 The UserTransaction interface can always
be used in the following components:
 Web components (JSPs and Servlets)
 Session beans with bean-managed transactions
enabled.
Interfaces implemented in
javax.transaction
 StatusThe Status interface defines static variables used
for transaction status codes.
 SynchronizationThe transaction manager provides a
synchronization mechanism that allows involved parties
to be notified before and after a transaction completes.
 TransactionThe Transaction interface allows operations
to be performed against the transaction in the target
Transaction object.
 TransactionManagerThe TransactionManager interface
defines the methods that allow an application server to
manage transaction boundaries.
 UserTransactionThe UserTransaction interface defines
the methods that allow an application to explicitly
manage transaction boundaries.
Packages cont’d
 javax.transaction.xaProvides the
API that defines the contract between
the transaction manager and the
resource manager, which allows the
transaction manager to enlist and
delist resource objects in JTA
transactions.
Interfaces in javax.transaction.xa
 XAResourceThe XA Resource
interface is a Java mapping of the
industry standard XA interface based
on the X/Open CAE Specification
 XidThe Xid interface is a Java
mapping of the X/Open transaction
identifier XID structure.
 XAExceptionThe XAException is
thrown by the Resource Manager
(RM) to inform the Transaction
Manager of an error encountered by
the involved transaction.
Transaction Functions
 begin() - Create a new transaction
 commit() - Complete the current
thread's transaction
 rollback() - Abort the current thread's
transaction
 setRollbackOnly() - Ensure that the
transaction must rollback
Code Sample





import javax.naming.*;
import javax.transaction.*;
import javax.sql.*;
import javax.ejb.*;
import javax.jms.*; import
java.sql.*;
// This code fragment sits Inside a session bean.
// The instance variable ctx represents a
SessionContext. UserTransaction ut
=ctx.getUserTransaction();
ut.begin();
// Each of these environment entries is arbitrarily named
and would be set in the EJB's
// deployment descriptor, and set up in the J2EE server's
administration tool.
DataSource ds1 = (DataSource)
ic.lookup("java:comp/env/jdbc/DatabaseOne");
DataSource ds2 = (DataSource)
ic.lookup("java:comp/env/jdbc/DatabaseTwo");
QueueConnectionFactory qcf = (QueueConnectionFactory)
ic.lookup("java:comp/env/jms/JMSQ");
try {
// perform work with the three
resources ut.commit(); }
catch (Exception e)
{ ut.rollback(); }
finally { // close resources }
References:
 http://www.subrahmanyam.com/artic
les/jts/JTS.html
 http://edocs.beasys.com/wls/docs60/
jta/gstrx.html#1018509
 http://www.theserverside.com/article
s/article.tss?l=Nuts-and-Bolts-ofTransaction-Processing
 http://java.sun.com/products/jts/java
doc/index.html
Reference cont’d
 http://www128.ibm.com/developerworks/java/lib
rary/j-jtp0305.html
 http://www.codenotes.com/articles/a
rticleAction.aspx?articleID=77
QUESTIONS ????
Session Bean
 A session bean is a type of enterprise bean;
a type of EJB server-side component.
Session bean components implement the
javax.ejb.SessionBean interface and can be
stateless or stateful. Stateless session
beans are components that perform
transient services; stateful session beans
are components that are dedicated to one
client and act as a server-side extension of
that client.
 A smart component could check on the current status
of the transaction and potentially save resources by
not performing work that would be lost anyway. This
would involve calling UserTransaction.getStatus(),
which returns an int constant defined on the
javax.transaction.Status interface:
 STATUS_ACTIVE - A transaction is active.
 STATUS_COMMITTED - The last active transaction was
committed.
 STATUS_COMMITTING - The last active transaction is
committing.
 STATUS_MARKED_ROLLBACK - Marked for rollback,
perhaps by setRollbackOnly()
 STATUS_NO_TRANSACTION - No transaction is active
 STATUS_PREPARED - A two-phase commit finished
the prepared (1st) phase.
 STATUS_PREPARING - A two-phase commit is inside
the prepared phase.
 STATUS_ROLLEDBACK - The last active transaction
was aborted.
 STATUS_ROLLING_BACK - The last active transaction
is aborting.
 STATUS_UNKNOWN - The transaction manager has no
idea. (Try again later.)
Java Transaction APIs architecture:
JTA

In computing, Common Object Request Broker Architecture (CORBA) is a
standard for software componentry, created and controlled by the Object Management
Group (OMG). It defines APIs, communication protocol, and object/service information
models to enable heterogeneous applications written in various languages running on
various platforms to interoperate. CORBA therefore provides platform and location
transparency for sharing well-defined objects across a distributed computing platform.

In a general sense CORBA “wraps” code written in some language into a bundle
containing additional information on the capabilities of the code inside, and how to call
it. The resulting wrapped objects can then be called from other programs (or CORBA
objects) over the network. In this sense, CORBA can be considered as a machinereadable documentation format, similar to a header file but with considerably more
information.

CORBA uses an interface definition language (IDL) to specify the interfaces that objects
will present to the world. CORBA then specifies a “mapping” from IDL to a specific
implementation language like C++ or Java. This mapping precisely describes how the
CORBA data types are to be used in both client and server implementations. Standard
mappings exist for Ada, C, C++, Lisp, Smalltalk, Java, and Python. There are also nonstandard mappings for Perl and Tcl implemented by ORBs written for those languages.
The CORBA IDL is only one example of an IDL.
