Jason's Tech Blog

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

JBoss Application Server (AS) 7 is due for release in early June. We can expect much faster load time, and a leap forward towards JEE 6 compatibility. I work in Red Hat JBoss support, with intimate knowledge of JBoss Enterprise Application Server 5. We were introduced to JBoss AS 7 by Stuart Douglas, who is a lead developer, working on the JBoss AS 7 development team. This a brief overview of the things we learned about JBoss AS7, and one of JEE 6′s key features Context Dependancy Injection, or CDI.

CDI and it’s JBoss implementation, Weld

The Context Dependency Injection (CDI) part of the Java Enterprise Edition (JEE) 6 specification is implemented by Weld on JBoss AS 7. Anyone who has used JBoss Seam will have a head start learning CDI. CDI is a product of the JSR-299 specification, who’s lead is Gavin King, [1]. CDI and Weld allow us to easily use objects from the business layer of an application, in the presentation layer. Previously programmers were forced to save the state of the their business objects in the HTTP Session between server requests, to maintain state between HTTP Requests. CDI leverages the strengths of the HTTP protocol, and Java Server Faces, and hides the complexity of the implementation in the application server (JBoss) logic.

Dependency Injection (DI) has already been used for many years in Java programming. However developers have had to rely on frameworks like Spring in order to achieve it. EJB does provide ways to inject objects, but no way to limit the scope of those objects. CDI provides a DI framework, like spring, with a wider variety of scopes, such as the Request, and Conversation scopes. Leveraging DI, while saving web developers the trouble of managing the scope of the business objects between HTTP Requests.

Anyone who is familiar with Seam 2 will understand the Request and Conversation scopes. The request scope is analogous to a HTTP Request, objects that are created within this scope survive only for a single HTTP Request, so will not be available on the next page, after a redirect. A Conversation scope is longer than a Request Scope, but often shorter than the Session scope. In CDI, a programmer has to decide when a conversation will begin and end. The conversation scope allows a programmer to keep objects alive across multiple web requests, such as during a shopping cart page flow, but avoid having to use a HTTP Cookie, or the Session object directly to store the object. For an in depth, discussion on these scopes, you should read Seam in Action, by Dan Allen [2]. While this book is about Seam 2, the concepts are relevant to CDI and Weld.

Another added benefit of CDI is Type Safety of DI. In Seam 2, and JSF Managed Beans, which object to inject was decided based on a String representation. In CDI, the object type is used to lookup injected beans in the container. For example in Seam 2:

@Name(“myBean”)
public class MyBean{
…
}

It is possible to compile a class which injects ‘myBean’ into a String like like:

@In
private String myBean

This will compile OK, but at runtime will fail, because the property ‘myBean’, is not of type ‘MyBean’

However in CDI, this will fail at compile time, allowing the programmer to notice the problem sooner, and also the Integrated Development Environment (IDE), to notify the programmer of the issue.

CDI and Weld have merged presentation, and business logic layers of an application together. Now we can easily assess our business logic in the presentation layer, without having to use the HTTP Session directly to maintain state on the server.

Performance Improvements

One of the big advantages JBoss AS 7 has over previous versions is the startup time. JBoss Enterprise Application Platform EAP 5, on the average 2.5 GHZ, 3 GB machine, would take about 30 – 60 seconds to load, without any applications installed. This was a real pain in the neck for any developer bootstrapping JBoss during a project build. You will be happy to know that AS 7 takes as little as 6 seconds to start on the same machine. AS 7 achieves this superior speed through Modular Classloading, and the Modular Service Container.

Module Classloading is a new approach to classloading from previous versions of JBoss. One of the main areas of frustration for a developer trying to migrate between application servers is the that the application servers handle classloading differently from each other. JBoss, as of AS 7 strictly enforces which classes are available to deployed applications. While JBoss allows deployed applications to access the API’s it provides, such as CDI, it does not expose it’s dependencies, read more in this community article by Jason Greene, [3]. This will avoid many problems with classloader conflicts, because you have to explicitly allow deployed applications to see, and use JBoss’ dependencies. Modular classloading makes the lookup of dependencies simpler, because the scope of available classloaders is more narrowly defined. In previous version of JBoss a scan of the application server’s classpath happened every time you loaded a new class, in the new classloading model class dependancies are resolved using a simple hashmap, greatly increasing it’s speed and efficiency.

The Modular Service Container (MSC) is a complete rewrite of the JBoss Microcontainer used in EAP 5. JBoss provides many JEE 6 services to application developers, and also uses those services for it’s internal functions. While previous versions of JBoss provided a way to resolve dependancies between services, MSC has added extra features to resolve and load services dynamically. In AS 7, when you deploy an application that has a dependency on a service, such as CDI, and CDI, has not already be started by JBoss, it will start that service dynamically. Similarly when you remove that same application, and JBoss detects that there are no other applications, or services that require CDI, JBoss will stop it. Previous versions of JBoss where more resource intensive, because it loaded all available services, whether you needed them in your applications or not, and you had to do a lot of work to remove services, see the Slimming guide for JBoss 5, [4]. This fine-grained approach to slimming AS 7 will no longer be required, because JBoss is now capable of dynamically detecting and resolving dependancies to it’s services.

Module classloading and the MSC, dramatically reduce the startup time of JBoss. This will allow developers to run an integration test suite against JBoss in far less time, and improve their productivity. The dynamic dependancy resolution of the MSC means that application administrators will need less intimate knowledge of JBoss to reduce the memory footprint, and disk space required to run JBoss.

Easy Configuration

Previous versions of JBoss EAP spread configuration of it’s components across many files. JBoss AS 7 provides a single file for configuration. The current version of the Enterprise edition, EAP 5 provided twiddle, as a command line interface to JMX MBeans, to control the server from the command line. JBoss AS 7 will make the command line, and a Java API, the primary way to make configuration changes on the server. It’s command line interface offers tab completion, and extensive array of commands that allow you to remotely manage and monitor the server, and deployed applications.

JBoss AS 7 comes with a new way to manage a JBoss cluster. While previous releases required server configurations changes be manually propagated to each node in the cluster, the AS 7, domain mode automates the task of makes changes to all nodes in a cluster. Domain mode starts 3 Java processes, one JBoss instance, a host process, and process controller. One node in the cluster will be the master node, and it is responsibly for pushing configuration changes, and deployed applications out to all nodes in the cluster. It has various smarts to group nodes, thereby isolating them from other cluster nodes.

In this article I have covered some of the key features of JBoss Application Server 7. The features I covered where the JEE 6 specifications CDI’s implementation called Weld, AS 7′s performance improvements, and it’s new easier configuration model. Many people who work in Java Web Development will be pleased to learn that JBoss understands Request and Conversational scopes, and can feel liberated programming against the CDI specification, because it allows them to move to a different application server in future, preventing the dreaded vendor lock in. I hope you have found this article useful to learn more about what is in the pipeline for JBoss. Red Hat is very excited about using these features in future releases of EAP.

Jason Shepherd
jason@jasonshepherd.net
Red Hat Middleware Support Engineer
JBoss 5 Certified Enterprise Application Administrator
Spring 2.5 Certified Professional
Java SE 6 Certified Professional

[1] http://www.jcp.org/en/jsr/detail?id=299
[2] Seam In Action, Dan Allen, 2008, http://www.manning.com/dallen/
[3] http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
[4] http://community.jboss.org/wiki/JBoss5xTuningSlimming