declarative-vs-programmatic-transactions

Developers need to control transaction boundaries (when they start and end), but writing transaction code in business logic is tedious and error-prone. There are two approaches: let the container handle it (declarative) or write it manually (programmatic).

Declarative (CMT): Container automatically starts/commits transactions based on XML configuration — no transaction code in bean. Programmatic (BMT): Bean explicitly calls begin() and commit()/abort() in Java code. Session beans and MDBs can use either; entity beans MUST use CMT.

Declarative (CMT)

1. Set <transaction-type>Container</transaction-type> in ejb-jar.xml
2. Container intercepts method call → calls begin() on transaction service
3. Delegates to bean for business logic
4. Bean returns (or signals abort via exception/setRollbackOnly())
5. Container calls commit() or abort() on transaction service
6. Bean and client are unaware of transaction mechanics

Programmatic (BMT)

1. Set <transaction-type>Bean</transaction-type> in ejb-jar.xml
2. Bean manually calls begin() at start of transaction
3. Bean performs business operations
4. Bean calls commit() or abort() at end
5. Full control over transaction boundaries — can have mini-transactions within a method

• Built from: Transactions — CMT and BMT are demarcation styles
• Built from: Transaction Demarcation — the 3 ways to demarcate
• Builds into: Entity Bean Transaction Rules — entity beans MUST use CMT
• Related: MDB — MDBs can use BMT or CMT
• Related: Session Bean — session beans can use BMT or CMT
• Contrasts with: Client-Initiated — third demarcation style

• Entity beans (BMP/CMP) CANNOT use BMT — it’s illegal (container calls ejbLoad/ejbStore, not bean)
• BMT requires careful handling: forgetting commit() leaves transaction open
• CMT transactions apply to entire method (can’t have mini-transactions)
• Client-initiated transactions are separate from BMT/CMT (client controls, bean still uses BMT/CMT internally)