Enterprise JavaBeans 3.1, 6th Edition

Transactions

As a routine chugs along, it may perform half of its duties before encountering some exceptional circumstance that prevents successful completion. At this point, the system may be left in an unreliable or incorrect state. Take the popular “account transfer example”:

1. User requests that $100 be transferred between her checking and savings accounts.

2. System deducts $100 from checking.

3. An unexpected error is thrown up the call chain.

The money has disappeared from record, and the customer is out $100. Although this may be a desirable scenario if you’re a particularly scheming bank manager, in most cases we’d like our programs to reliably leave things in consistent state. EJB ensures this via its integration with the Java Transaction Service (JTS; http://java.sun.com/javaee/technologies/jts/) and exposes an API that gives the bean provider (application developer) control over the properties specifying how a transaction-aware application behaves. Again, the nuts and bolts of how this is achieved is not a problem for the EJB developer; all that’s required is some understanding of the ACID^[7] fundamentals:

Atomicity

Every instruction in a call completes or none do. If there’s a failure halfway through, state is restored to the point before the request was made.

Consistency

The system will be consistent with its governing rules both before and after the request.

Isolation

Transactions in progress are not seen outside the scope of their request until successful completion. Shared resources ...