Transaction policy: API Layer Policy-Learn how to implement a simple and robust transaction strategy

Introduction: An effective and robust transaction strategy is critical for maintaining data consistency and integrity. API Layer transaction policies are easy to implement and are ideal for most business applications. The author of the Transaction Policy series, Mark Richards, uses an example of the Enterprise JavaBeans (EJB) 3.0 specification to explain what the transaction strategy means and how to implement it on the Java™ platform.

Whether you are using a container environment in EJB 2.1 or 3.0, or using the Spring Framework environment, or a WEB container with Java Open Transaction Manager (JOTM) such as Tomcat and Jetty Environment, a transaction strategy is needed to ensure consistency and integrity of the database. The Java Transaction API (JTA) specifies the syntax and interfaces associated with transaction processing, but does not describe how to combine these building blocks. Just as construction workers need to build a house out of a pile of wood based on a design plan, you need a strategy to describe how to combine transaction building blocks together.

About this series

Transactions can improve the quality, integrity, and consistency of data and make your applications more robust. Achieving successful transaction processing in a Java application is not easy, it involves design and coding. In this series, Mark Richards will guide you through the design of effective transaction strategies for various use cases ranging from simple applications to high-performance transactions.

The policy name I will describe in this article is the API Layer transaction policy. It is the most robust, simple, and easy to implement transaction strategy. But the simplicity also brings with it some limitations and factors to consider, which I will explain. I use the EJB 3.0 specification in the code example, and the same concept applies to the Spring Framework and Jotm.

Basic structure

The naming of API Layer transaction policies is based on the fact that all transaction logic is contained in the API layer of the logical application architecture. This layer is a logical layer-sometimes referred to as the domain layer of the application or the façade layer, which exposes functionality to the client (or presentation layer) in the form of public methods or interfaces. The logic layer is because it is possible to access the domain layer from the local (through direct instantiation and invocation) or through HTTP, remote method call (RMI), the RMI over Internet Inter-ORB Protocol (RMI-IIOP) through EJBS, and even through the Ja VA message Service (JMS) for remote access.

Figure 1 shows a typical stack of logical application tiers for most Java applications:

Figure 1. Schema layer and transaction logic

The schema in Figure 1 implements the API Layer transaction strategy. Classes that contain transaction logic are represented with a red background. Note that these include only the domain class (API layer) of the application schema. The client tier, business layer, and presentation layer do not contain transaction logic, meaning that they do not start, commit, or rollback transactions, nor do they include transaction annotations, such as @TransactionAttribute annotations in EJB 3.0. The only way to start, commit, and rollback transactions throughout the application schema is the public methods contained in the domain classes in the API layer. This explains why the API layer is the most robust and simple transaction strategy.

Do not confine yourself to the 4 layers shown in Figure 1. An application architecture can contain more layers, or it may contain fewer layers. You can combine the presentation layer and the domain layer into a single WAR file, or place the domain class in an EAR file alone. You might use the business logic contained in the domain class as a layer, not two. None of this affects how the transaction policy works or how it is implemented.

This transaction strategy is ideal for applications that have a coarse-grained API layer. And because the presentation layer does not contain any transaction logic (even update requests), this strategy is ideal for applications that must support multiple client channels, including WEB service clients, desktop clients, and remote clients. But this flexibility has to pay a price-that is, the client layer is limited to a single request for a given transactional unit of work. I will explain the need for this limitation later in this article.