|
The Developer's Resource & Community Site
|
Transactions, 2PC and JTS
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Java Transaction Service, Two-phase commits
Pre-required Reading: Enterprise JavaBeans
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 https://www.onelist.com/community/dev-java).
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)
Author: Gopalan Suresh Raj
Date Submitted: January 6th 2000
Level of Difficulty: Advanced
Subjects Covered: Enterprise JavaBeans, EJB Server, EJB Architecture, Java Naming and Directory Interface, Java Transaction Service.
Pre-required Reading: None
Enterprise Java Beans Series - Components at the Server By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Server side components, CORBA
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Model By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Enterprise JavaBeans, EJB Server, EJB Containers, EJB Clients.
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Naming Services and JNDI By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Naming Services, Java Naming Directory Interface
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Lifecycle By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: EJB server provider, EJB container provider, EJB developer, EJB deployer, Application developer.
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Servers By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Server Infrastructure
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Containers By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: EJB Containers, EJB Servers
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Components By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: EJB Object, Home Object, Remote Object
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Session Beans By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Stateful Session Beans, Stateless Session Beans
Pre-required Reading: Enterprise JavaBeans
Enterprise Java Beans Series - EJB Entity Beans By Gopalan Suresh Raj.
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Container-Managed Persistence, Bean-Managed Persistence
Pre-required Reading: Enterprise JavaBeans
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
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Developing Entity Beans, Home & Remote Interfaces, Data Sources.
Pre-required Reading: Enterprise JavaBeans
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
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Developing Session Beans, Home & Remote Interfaces, Deployment Descriptors.
Pre-required Reading: Enterprise JavaBeans
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
Author: Gopalan Suresh Raj
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: EJB Clients.
Pre-required Reading: Enterprise JavaBeans
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
Date Submitted: January 11th 2000
Level of Difficulty: Advanced
Subjects Covered: Servlet Clients.
Pre-required Reading: Enterprise JavaBeans
Author: Gopalan Suresh Raj
Gopalan has his own site at Author Central (visit him. He also maintains his own site at https://www.execpc.com/~gopalan/) - Contribute to iDevResource.com and you can have one too!
© Copyright 1997-2000 Gopalan Suresh Raj. Reproduced with Permission
|
