Transactions 101
A transaction usually means a sequence of information exchange and related work (such as a database update) that is treated as a unit. Although transactions are usually isolated from each other, so that one will not effect the other, until the unit of work is completed, it is possible to relax this restriction in certain situations, such as when using systems located across a Wide Area Network (WAN).
Transactions in the Java Enterprise Programming world today usually involve databases and Java Remote Method (RMI) queues. Transactions that involve a single system, such as a database, are the simplest form of transaction, because they do not need coordination with other systems. However in today's Enterprise IT environment, business requirements often dictate that a transaction span multiple systems, such as a database and RMI queue, or two databases. In the event that transactions span multiple systems, it will be up a third party to coordinate the transaction. In the Enterprise Java world this service is provided by an application server container, such as JBoss.
Transactions have been a feature of application servers for many years now, and are generally very robust. A.C.I.D. is a basic principle that is a feature of traditional transactions. The A.CI.D. principal stands for Atomic, Consistent, Isolated and Durable.
- Atomicity refers to the gathering of task together to form a single task. Either all of the task, or none of the task occur, but if a group of tasks is atomic, they should never only partially complete.
- Consistency means that we must run checks before, and after the transactions to make sure that they can be performed before the transaction starts, and they where completed successfully when the transaction completes.
- Isolated means that separate tasks execute serially, never will a partially completed transactions be visible to anther transactions, their result should only be visible once the transaction has completed. Although isolation can be traded for performance.
- Durable meaning that if we say we will complete a task, we must make sure they it completes, even in the event of a system crash.
The way that A.C.I.D. Transactions are usually implemented, is via two phase commit. Two phase commit is broken down into two steps, or phases. Step one is, asking can “I perform the requested task?”. Step two is, if all tasks in a transaction can be completed, I must go ahead and complete them. This is similar to what occurs in a marriage, two parties, a man and woman communicating with a clergy man. The clergy man ask, do you take this man/woman, once the two parties agree, the two are married. See this overview of traditional transactions here, [1].
[1] http://www.ibm.com/developerworks/java/library/j-jtp0305/index.html
Some key terms we need to understand in order to talk about transactions are listed here.
"Transactional Manager" (TM) is the clergy man, the one responsible for controlling the transaction.
"Resource Manager" maintains the state of a resource during a transaction. It usually includes a driver for translating between the TM, and a resource, such as a database.
Transactions in a distributed system.
One way to group units of work, or business logic, into a transaction, is to use Enterprise Java Beans (EJBs). If you use EJBs, JBoss will automatically provide transactions for you, using the Java Transaction API (JTA). If you want to run business logic in two different Java Virtual Machines, or application servers, such as two JBoss nodes, you can use a Remote EJB lookup, and that business logic will automatically join the existing transaction. This is implemented transparently by Java Transaction Service (JTS) on JBoss. See definitions of JTA [2], and JTS [3].
[2] http://en.wikipedia.org/wiki/Java_Transaction_API
[3] http://java.sun.com/products/jts/jts-spec0_95.pdf
While transactions in a single container can be handled by JTA, if transactions need to distributed between application servers, there needs to be some common ground, so that the transaction can be shared between the two application servers. If you are trying to achieve this between two different Java Virtual Machines, you need the Java Transaction Service, (JTS), which is a Java implementation of the CORBA OTS. Implementing the CORBA OTS allows transactions to be distributed between a Java and non Java Transaction Manager.
You may be asking yourself, why do we need to use two transaction managers, if all our resource managers know how to speak JTA? Can't we just enlist resources from a remote JVM and interact with them directly? Well, you could do it that way, but there will be a lot of network traffic between the JVMs. By allowing multiple resources in a remote JVM to talk with a TM that is local to them, and have only the two TMs communicating across the network. This is referred to an interposition, and is a performance optimization provided by JTS. JBoss, and it's implementation on JBoss provides interposition for you by default.
Transactional Web Services
While many businesses today are using web services, many are not actually utilising technology to make sure that their business activities follow ACID principles. This could be due to several factors, including complexity implementing the technology, and an apparent lack of standards, and therefore interoperability between application servers. JBoss is tackling these issues, and has been for quite some time, see this blog post, by Mark Little, from Red Hat [4].
[4] http://jbossts.blogspot.com/2007/07/trying-to-put-jbossts-into-perspective_6770.html
JBoss currently offers WS-C (WS-Coordination), and WS-AT (WS-Atomic) for use in JBoss to implement transactional web services within an Intranet. There is another standard available called WS-BA (WS-Business Activity), which will allow transaction to span out to disparate web services across a WAN, but several more features are yet to implemented, which will make this easy for business programmers to adopt.
WS-AT is based on the traditional model of transactions, in that during the prepare phase of a two phase commit, resources are locked, so that transactions can remain isolated from each other. This is not practical in a WAN environment, where network communications may take a long time to respond, or where systems are not under the control of a single system administrator. Amazon would not tolerate holding a lock on a book for several days, or even hours, while a third party payment processor is down due to a system failure.
WS-BA is a model that allows resources to commit early, and worry about rolling back changes later, if a transaction cannot be completed. Obviously this a more practical model for applications that rely on (web) services from third party vendors, who's service cannot be guaranteed. System administrators no longer have to worry about locks being held by third party services, because their resource commit early, and wait to hear back from third party services if things require a rollback, in an a-synchronise fashion.
Because WS-BA is an extension of the traditional transactional model, at the current time, application developers will need to write there own resource managers, while the WS-AT implementation in JBoss provides automatic bridging. Automatic bridging is possible because WS-AT closely resemble traditional transactions involving databases. Bridging is to WS-AT, what Hibernate is to JDBC, it greatly simplifies things for business programming wanting to implement WS-AT for their web service.
JBossTS XTS is JBoss's implementation of WS-AT, and WS-BA. If you want to learn more about JbossTS, you should read the very extensive JBossTS XTS programmers guide, [5]. You can also download an example, that demonstrates the use of WS-AT for an intranet, in the JTA Full distribution, in the latests release, at the time of writing, 4.15, [6], and the release that is included in EAP 5.1, version 4.6.1, [7].
[5] http://docs.jboss.org/jbosstm/docs/4.2.3/manuals/html/xts/ProgrammersGuide.html
[6] http://www.jboss.org/jbosstm/downloads/4.15.0.Final/src/jbossts-full-4.15.0.Final-src.zip
[7] http://www.jboss.org/jbosstm/downloads/4.6.1.GA/src/jbossts-full-4.6.1.GA-src.zip
This article was written after Red Hat training conducted by two members of the JBoss Transactions engineering team, Jonathan Haliliday, and Andrew Dinn.
Jason Shepherd
Red Hat Middlware Support Engineering