Library Zone Articles
External Articles
Byte Size

Discovery Zone Catalogue
Interactive Zone Ask the Gurus
Discussion Groups
Etc Cartoons
Advertising ASP Web Ring ASP Web Ring
Click here
The Developer's Resource & Community Site
International This Week Forums Author Central Find a Job

Transactions, 2PC and JTS

What are Transactions?

The most important concept that you have to be aware of when dealing with enterprise applications is the concept of a transaction. To a user, a transaction is a single change event that either happens or doesn't happen. To system implementers, a transaction is a programming style that allows them to code modules that can participate in distributed computations. To illustrate the concept, let us assume that you want to transfer money from a savings account into a checking account. In this scenario, it is critical that both the accounts are changed from a successful transaction and neither is affected from an unsuccessful one. You just cannot afford to have your money vaporize if crediting your checking account fails for any reason after the debit on your savings account! Although this may sound like a fairly straightforward request, it is hard to make this work in a distributed system without deploying some form of transaction control - computers can fail and messages can be easily lost.

Transactions provide a way to bundle a set of operations into an atomic execution unit.

This atomic "all-or-nothing" property is not new: it appears throughout life. For example, a minister conducting a marriage ceremony first asks the bride and groom, "Do you take this person to be your spouse?" Only if they both respond "I do" does the minister pronounce them married and commit the transaction. In short, within any transaction, several independent entities must agree before the deal is done. If any party disagrees, the deal is off and the independent entities are reverted back to their original state by invoking a rollover operation

Transactions are essential for distributed applications. Further, transactions provide modular execution, which complements a component technology’s modular programming.

The ACID properties

All transactions subscribe to the following "ACID" properties:

  • Atomicity: A transaction either commits or rollbacks. If a transaction commits, all of its effects remain. If it rollbacks, then all of its effects are undone. For example, in renaming an object, both the new name is created and the old name is deleted (commit), or nothing changes (rollback).
  • Consistency:A transaction always leads to a correct transformation of the system state by preserving the state invariance. For example, a transaction adding an element to a doubly linked list, all four forward and backward pointers are updated.
  • Isolation:Concurrent transactions are isolated from the updates of other incomplete transactions. This property is also often called serializability. For example, a second transaction traversing a doubly linked list already undergoing modification by a first transaction will see only completed changes, and be isolated from any non-committed changes of the first transaction.
  • Durability:If a transaction commits, its effects will be permanent after the transaction commits. In fact, the effects remain even in the face of system failures. It is up to the application to decide what consistency is and to bracket its computation to delimit these consistent transformations. It is the job of the transactional resource managers to provide consistent, isolated and durable transformations of the objects they manage. If the transactions are distributed among multiple computers, the two-phase commit protocol is used to make these transactions atomic and durable.

The Java Transaction Service

The Java Transaction Service (JTS) plays the role of a transaction coordinator for all the constituent components of the EJB architecture. In JTS terminology, the director is called the transaction manager. The participants in the transaction that implement transaction-protected resources such as relational databases are called resource managers. When an application begins a transaction, it creates a transaction object that represents the transaction. The application then invokes the resource managers to perform the work of the transaction. As the transaction progresses, the transaction manager keeps track of each of the resource managers enlisted in the transaction.

The application's first call to each resource manager identifies the current transaction. For example, if the application is using a relational database, it calls the JDBC interface, which associates the transaction object with the JDBC connection. Thereafter, all calls made over that connection are performed on behalf of the database transaction until it ends.

Typically, the application completes the transaction by invoking a xa_commit() method and the transaction is said to commit. If the application is unable to complete for any reason, it performs a rollover by calling the xa_rollback() method which undoes the transaction's actions. If the application fails, the JTS aborts the transaction. When the application successfully completes the transaction's work, it calls the JTS to commit the transaction. The JTS then goes through a two-phase commit protocol to get all of the enlisted resource managers to commit.

Two-phase commits

The two-phase commit protocol ensures that all the resource managers either commit a transaction or abort it. In the first phase, the JTS asks each resource manager if it is prepared to commit. If all the participants affirm, then in the second phase the JTS broadcasts a commit message to all of them. If any part of the transaction fails - for instance, if a resource manager fails to respond to the prepare request, or if a resource manager responds negatively, then the JTS notifies all of the resource managers that the transaction is aborted. This is the essence of the two-phase commit protocol.

What do you think of this article?

Have your say about the article. You can make your point about the article by mailing [email protected] (If you haven't allready joined, you can join by going to

You can also write a review. We will publish the best ones here on this article. Send your review to [email protected]. Please include the title of the article you are reviewing.

Further Reading

The Enterprise JavaBeans Series:

Enterprise Java Beans By Gopalan Suresh Raj.
In this introduction to Enterprise Java Beans, Gopalan covers the bases then goes on to demonstrate how to build server side business object components. This article is the introduction to Gopalans series of Enterprise JavaBeans articles. (This series of articles is courtesy of Gopalan Suresh Raj)

Enterprise Java Beans Series - Components at the Server By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Model By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Naming Services and JNDI By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Lifecycle By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Servers By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Containers By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Components By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Session Beans By Gopalan Suresh Raj.

Enterprise Java Beans Series - EJB Entity Beans By Gopalan Suresh Raj.

Enterprise Java Beans Series - Writing an Entity Bean By Gopalan Suresh Raj.
Part 1 of a four part series: A four tier bank account example

Enterprise Java Beans Series - Writing a Session Bean By Gopalan Suresh Raj.
Part 2 of a four part series: A four tier bank account example

Enterprise Java Beans Series - Writing an EJB Client By Gopalan Suresh Raj.
Part 3 of a four part series: A four tier bank account example

Enterprise Java Beans Series - Writing an EJB Servlet Client By Gopalan Suresh Raj.
Part 4 of a four part series: A four tier bank account example

Author: Gopalan Suresh Raj

Gopalan has his own site at Author Central (visit him. He also maintains his own site at - Contribute to and you can have one too!

© Copyright 1997-2000 Gopalan Suresh Raj. Reproduced with Permission

Contribute to IDR:

To contribute an article to IDR, a click here.

To contact us at, use our feedback form, or email us.

To comment on the site contact our webmaster.

Promoted by CyberSavvy UK - website promotion experts

All content © Copyright 2000, Disclaimer notice

WTL Introduction

WTL Architecture by Richard Grimes

Visit the IDR Bookstore!

Java COM integration