ACID:
Atomicity: Either should commit all rollback all of its updates in a single unit of work.
Consistency: database should never be left in inconsistent state
Isolation: How protected is uncommitted changes from other transactions, isolation decreases concurrency.
Durability: changes are permanent.
interfaces
UserTransaction begin(), commit(), rollback(), getStatus()
TransactionManager suspend(), resume(), setRollbackOnly(),
Status ACTIVE, COMMITTED, COMMITING, MARKED_ROLLBACK, NO_TRANSACTION, PREPARED, PREPARING, ROLLEDBACK, ROLLING_BACK, UNKNOWN.
Transaction Models
1. Local
2. Programatic
3. Declarative
Local Transaction Model:
Resource manager manages transactions. Developer manages connections.
e.g.
conn.setAutoCommit(false);
try {
stmt.executeUpdate(sql1);
stmt.executeUpdate(sql1);
conn.commit()
} catch (Exception e) {
conn.rollback();
}
Programatic Transaction Model
Uses JTA, developer uses UserTransaction begin(), commit() or rollback().
UserTransaction tx
tx.begin()
tx.commit()
tx.rollback()
Doesn't scale if calling one service from other.
Declarative Transaction Model:
CMT, container's manages transactions, developer should tell Spring, EJB where to being etc.
@Transactional
Patterns
1. Client Owner Transaction Design Pattern
Forces:
1. The client requires multiple remote calls to fulfill a single business request.
2. ACID properties must be maintained
3. Domain service objects are fine-grained and no aggregate service exist.
4. Not possible to re-architect.
Solution:
client is responsible for transactions
Consequences:
client should use programmatic tx or declarative if spring is used.
spring doesn't support remote tx
2. Domain Service Owner Transaction Design Pattern
typical web app
3. Server Delegate Owner Transaction Design Pattern
forces:
Command Pattern or Server Delegate Pattern
client makes a single request to a server delegate
command processor is the entry point
Comments