Head First EJB

The ACID test

Is your transaction safe?

Five out of five experts (plus pretty much the entire rest of the industry) agree on four characteristics of a good, safe transaction. (This is not just an EJB thing, by the way—the ACID test goes back long before Java was a gleam in Gosling’s eye.) To put your transactions through the ACID test, make sure the transaction is:

Atomic

• Either it all works, or it all fails (and rolls back).

• A transaction isn’t atomic if it’s possible for some of it to commit while other parts don’t.

Consistent

• Whether it works (commits) or fails (rolls back), the data should stay consistent with the business logic reality. You’d have real trouble if, say, you could take items out of inventory without actually submitting an order. You’d end up with items that exist in the real inventory (i.e. in a warehouse somewhere), but that don’t show up in anybody’s computer records.

Isolated

• Let’s say you have two different transactions running, potentially hitting the same database. You don’t want the effect of one transaction to corrupt the state of another transaction. In other words, the transactions should be protected (isolated) from one another. Isolation is very similar to thread synchronization—you don’t want one transaction reading some data (with the intention of acting on it) if that data is smack in the middle of another transaction that hasn’t finished committing its ...