transactions

Enterprise beans perform mission-critical tasks that must be reliable and robust. Without transactions, partial failures (e.g., debiting one account but not crediting the other) lead to data inconsistency. EJB abstracts low-level transaction systems so developers focus on business logic.

Transactions in EJB provide ACID properties (Atomicity, Consistency, Isolation, Durability) for enterprise bean operations. The EJB container abstracts the underlying transaction system — beans only vote on commit/abort, never interact directly with transaction managers.

1. EJB uses flat transactions (all-or-nothing, no nested transactions in EJB spec)
2. Transaction boundaries are demarcated via: Programmatic (BMT), Declarative (CMT), or Client-Initiated
3. Container handles: begin, commit, rollback — bean signals success/failure
4. Entity beans: ejbLoad() acquires locks → business methods run → ejbStore() writes and releases locks (all within one transaction)
5. Transaction spans entire set of operations or per-method depending on demarcation style

• ACID: Atomicity (all-or-nothing), Consistency (valid state), Isolation (concurrent tx don’t interfere), Durability (committed data survives crashes)
• EJB uses flat transactions (nested transactions NOT supported)
• Container abstracts low-level transaction system (bean never touches transaction manager)
• Entity beans load/store per transaction, not per method call
• Transaction attributes (in deployment descriptor) control when transactions start/end

• Built from: EJB Container — container manages transaction boundaries
• Builds into: Transaction Demarcation — 3 ways to control transactions
• Builds into: Entity Bean Transaction Rules — entity beans must use CMT
• Builds into: Flat vs Nested Transactions — EJB uses flat only
• Related: Poison Message — MDB rollback in CMT causes poison messages
• Related: CMT vs BMT — comparison of demarcation styles

• Nested transactions are NOT supported in EJB (despite being described in the book)
• Entity beans transaction spans ejbLoad → methods → ejbStore (not per individual method)
• If each entity bean method is a separate transaction, performance suffers (too many DB reads/writes)
• Client-initiated transactions over network have higher rollback rates (network failures)