Chapter 7: Transactions


Fundamentals

Transactions represent a multifaceted and valuable mechanism and a decided strength of the EJB concept. They make possible the development of important business processes in a multiuser and multiresource environment.

Transactions bind several steps of a process into a single processing unit; a transaction provides a path from one consistent state in a database to another consistent state; and a successfully executed transaction leads to a persistent change in the data. A typical EJB application uses a transaction to change the contents of a database.

The path to the next consistent state often leads over several steps and inconsistent intermediate states. Therefore, a transaction has the task of uniting a number of individual processing steps into a single unit. If in the course of a transaction there arises a condition that prohibits the proper completion of the transaction, then all actions in the transaction taken up to that point are canceled. That is, a transaction is either executed completely, or else it leaves no effect on the state of the data. Thus a transaction is referred to as atomic or inseparable.

A typical example of a transaction is a bank transfer (see Figure 7-1). Here a certain amount of money is transferred from one account into another. If an error occurs during the withdrawal from one account or the deposit into the other, then the original state of the accounts, as the last consistent state, must be restored.

click to expand
Figure 7-1: Bank transfer as example of a transaction.

It is highly desirable that other users of the same data always see consistent states. Therefore, the transaction mechanism can ensure that inconsistent states remain hidden. This property is called consistency of views or isolation of transactions.

In the case of parallel access to the same data by several clients there are three categories of problems. That is, there are three different reasons that a client might see an inconsistent state:

  1. Dirty Reads (inconsistency): At a particular moment there is an inconsistent state in the database (see Figure 7-1).

  2. Nonrepeatable Reads: A client reads the data over time, reading the first part at time A and the second at time B. Another client's transaction, running in parallel, modifies the same data in the interval between time A and time B. Even consistent states exist at times A and B, the reading client can nonetheless obtain a false view of reality.

    In the example of Figure 7-1 an inconsistent view could arise as follows: A client reads from Account 1 before the represented transaction, and from Account 2 after the transaction. The client obtains the false view of Account 1 having a balance of 100 and Account 2 a balance of 70.

  3. Phantom Reads: This problem arises when new data elements are added to the database. At time A, a client reads all the data elements that satisfy certain criteria, and at time B executes a write operation that depends on the result obtained at time A. If between time A and time B a new data element is written to the database that satisfies the same criteria, then the write operation at time B should have taken it into account.

    This problem can occur, for example, in storing articles. An article with a certain weight is to be stored. First it is determined whether the storage medium has the necessary capacity. The articles already in the store are determined, and their weights are totaled. If there is sufficient capacity remaining, the article is added to the list of articles in storage. If between the reading of the stored articles and the acceptance of the article into storage another article is taken into storage, the total capacity can be exceeded.

Present-day database systems are able to avoid these problems. Through the use of intermediate data storage for a running transaction (caching) and exclusive reservation of data elements (locking) for a transaction, each transaction can be guaranteed a consistent view. Each of these measures requires the expenditure of resources and thus diminishes the performance of the database.

Locking impairs the ability of transactions to run in parallel and in extreme cases can lead to the serialization of all transactions. To obtain complete consistency of views is thus expensive; that is, it has negative effects on the performance and parallelism of transactions. For this reason partial restrictions are accepted.

One distinguishes four levels of consistency (see [14] and the section on transaction isolation in this chapter). The quality of the consistency increases as the level rises from level 1 to level 4:

  1. The problems of dirty and nonrepeatable reads are accepted for the sake of improved performance.

  2. Only the problem of nonrepeatable reads is accepted. In contrast to level 1, here no inconsistency is permitted.

  3. Consistent results are endangered by the phantom problem.

  4. Complete consistency of views is always ensured.

The fundamental properties of transactions are frequently collected under the acronym ACID, which stands for atomic, consistent, isolated, and durable.

We distinguish between transaction management and transaction control. Transaction management (also called transaction demarcation) determines when a transaction begins and when it is ended or aborted. Transaction control is the technical implementation of the transaction mechanism. It consists of the communication mechanism for distributed transactions and the transaction monitor.

Compared to the theoretical knowledge that is necessary for an understanding of transactions, the programming of transaction management is very simple. Three commands form the basis for transaction management:

  • The command begin starts a transaction.

  • The command commit causes a transaction to end successfully.

  • The command rollback causes a transaction to be aborted.




Enterprise JavaBeans 2.1
Enterprise JavaBeans 2.1
ISBN: 1590590880
EAN: 2147483647
Year: 2006
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net