Weigh Apache Geronimo EJB transaction options, part 1th: Container Management transactions

This series is divided into three sections that explore the Enterprise Java™beans (EJB) container management transactions and bean management transactions in Apache Geronimo. In part 1th, you will find differences between the two transactions, including understanding how container management transactions can help you avoid the complexity of transaction logic and management, allowing you to focus on the business logic of enterprise beans. You will also learn how to implement container management transactions in the Geronimo application server, and how to use Geronimo, OPENEJB, and XDoclet to liberate yourself from heavy EJB coding efforts.

Brief introduction

OPENEJB is an instance of the EJB container selected for Apache Geronimo. Although EJB 3.0 is currently available, Geronimo does not support EJB until the Geronimo version 2.0 is released and Geronimo receives Java 1.5 certification.

This series, which is divided into three parts, will give you an idea of what Geronimo and OPENEJB can do for you, as well as the EJB transaction concepts that can now be implemented in EJB 2.1 (allowing you to successfully enter EJB 3.0).

The benefit of the EJB framework is that you can use transactions, but without the pain of transactional API programming. When implementing an EJB transaction, you have two choices:

Tell the EJB container to handle all the hard work (container-managed transactions).

Let the enterprise bean handle part of the transaction work (a bean-managed transaction).

In part 1th of this series, you start with an overview of the transaction, and then discuss the EJB container-managed transactions described in EJB 2.1. Finally, with some code snippets, this code shows how to implement container-managed transactions on the Geronimo application server.

In part 2nd, you will get an overview of the transactions managed by the Bean in EJB 2.1 and see some sample code implementations.

In part 3rd, the two transactions are consolidated and the challenges and additional attributes associated with the transaction and the transactions managed by the container are understood.

Transactions--Overview

What is a transaction? Why are they so important? Consider the very simple case of banking: transfer 100 dollars from one current account to your deposit account. By further investigation, this operation can be decomposed into two smaller operations:

The bank subtracts 100 dollars from your current account.

The bank adds 100 dollars to your savings account.

You may feel a little frustrated if the bank reduces the current deposit by 100 dollars, but your savings account does not increase by 100 dollars. Personally, I would like to treat two actions as an action. So if your savings account never adds 100 dollars, then 100 dollars should never be subtracted from your current account!

Similarly, in the application process, many business cases are confirmed as a whole (all-or-nothing approach). Some large operations consist of one or more smaller steps. In order to complete the operation, all steps in the operation must be completed or not completed, and this behavior is called atomic behavior.

Atomicity is one of the four characteristics (or attributes) that a transaction must guarantee. The other three properties are:

Consistency

Isolation of

Durability

Together, these four properties are called ACID properties.

ACID Properties

These known ACID properties are described by transactions as:

The transaction is atomic. All operations are considered to be a unit of work. As discussed above, it is confirmed by the whole.

Transactions are consistent. After a transaction has been executed, the system must be maintained in a consistent (or legal) state. The definition of a legal state depends on the system. According to an earlier example, after any undo operation is performed, the bank instructs you to keep your current account as a surplus.

The transaction is isolated. Each transaction is isolated from other transactions when it is operating on the same resource. This can be achieved through lock synchronization of data.

The business is persistent. Resource updates must avoid system failures, such as hardware or network failures. In a distributed system, the recovery process is required when a network failure or a database crash occurs.