Transaction policy: Understanding transaction Traps-common errors to be aware of when implementing transactions in the Java platform

Introduction: The goal of transaction processing should be to achieve high data integrity and consistency. This article is the first of a series of articles on developing effective transaction strategies for the Java platform, and describes some common transaction traps that prevent you from achieving this goal. The author of this series, Mark Richards, explains these extremely common errors by using the code examples in the Spring Framework and Enterprise JavaBeans (Enterprise JAVABEANS,EJB) 3.0 specification.

Transactions are often used in applications to maintain high levels of data integrity and consistency. If you don't care about the quality of your data, you don't have to use transactions. After all, transactional support in the Java platform degrades performance, raises locking issues and database concurrency issues, and increases application complexity.

About this series

Transactions improve the quality, integrity, and consistency of data, making applications more robust. Implementing successful transactions in a Java application is not an easy task, and design and coding are almost as important. In this new series of articles, Mark Richards will lead you through the design of an effective transaction strategy for a variety of use cases from simple applications to high-performance transactions.

But developers who don't care about the business will get into trouble. Almost all business-related applications require a high level of data quality. The financial investment industry is wasting tens of billions of of dollars on failed deals, and bad data is the second biggest contributor to this outcome. The lack of transactional support is only one factor (but the main factor) that leads to bad data, but it is perfectly understandable that the loss of billions of of dollars in the financial investment industry is due to a lack of transactional support or insufficient transaction support.

Ignoring transaction support is another cause of the problem. I often hear the phrase "We don't need transactional support in our applications because these applications never fail". Yes, I know some applications rarely or never throw exceptions. These applications are based on well-written code, well-written validation routines, and adequately tested, with code coverage support, to avoid performance loss and complexity associated with transaction processing. This type of application only needs to consider one feature of transaction support: Atomicity. Atomicity ensures that all updates are treated as a single unit, either committed or rolled back. But rolling back or updating at the same time is not the only aspect of transactional support. On the other hand, isolation will ensure that a unit of work is independent of other units of work. Without proper transaction isolation, other units of work can access updates made by an active unit of work, even if the unit of work has not yet been completed. This makes business decisions based on part of the data, which leads to failed transactions or other negative (or costly) results.

Better late than never.

I started focusing on transactional issues in the early 2000, when I was working on a client site, and I found that one of the project plans had priority over system test tasks. It is called implementing transaction support. Of course, it is easy to add transactional support to a major application when it is almost ready for system testing. Unfortunately, this approach is too common. At least this project (unlike most projects) does achieve transactional support, although at the end of the development cycle.

So, given the high cost and negative impact of bad data, and the importance (and necessity) of transactions, you need to use transactions and learn how to handle problems that may arise. Many problems often arise when you add transactional support to your application. Transactions do not always work as expected in the Java platform. This article will explore the reasons for this. I'll use code examples to introduce some of the common transaction traps I've seen and experienced in this area, mostly in the production environment.

Although most of the code examples in this article use the Spring Framework (version 2.5), the transaction concept is the same as in the EJB 3.0 specification. In most cases, replace the Spring Framework @Transactional annotations with the _cnnew1@transactionattribute annotation in the EJB 3.0 specification. If the two frameworks use different concepts and techniques, I'll give the Spring framework and EJB 3.0 source code examples as well.