Unit of work that accesses one more more resources (usually databases)
set of one or more activities related to each other
must be completed together or not at all
ATM
Withdraw from one source
Deposit to another
Order System
Locate item
Charge account
Schedule shipment
Medical System
Identify medical state
dispense prescription
AtomicAll parts of the transaction must complete or nothing at all
ConsistentResource (e.g., data in database) is in consistent state upon completion
State "makes sense"
Database constraints (primary keys, foreign keys, etc.) are satisfied
IsolatedTransaction executes without interference from outside the scope of the transaction
Can the transaction read state not yet committed by another transaction?
Can the transaction read state that did not exist prior to it starting?
DurableCommitted changes are not lost if system crashes after the commit completes
Rather than autocommit each command, a set of commands are executed within larger transaction
A failure of any of these commands or failure to commit -- will rollback all commands
Container will coordinate transaction with resource manager for database
Same as before except commands spread across multiple databases
Container will coordinate transaction with resource managers for all databases involved
Requires a distributed transaction -- transparent to commands executed
Avoid Distributed Transactions where Possible
Even though JTA transactions allow for the forming of a distributed transaction across multiple resources -- that does not mean you should design for that goal. Local transactions (single resource) are much faster than distributed transactions (multiple resources) and should be the primary goal in transaction design.
Same as before except commands issued to different types of resources
Message taken off queue only if overall transaction succeeds
Changes occur to database only if overall transaction succeeds
Message added to topic only if overall transaction succeeds
How Could You Avoid Distributed Transactions Here?
Many possibilities...
Design JMS interfaces to handle duplicate messages if work has to be repeated
Design database interaction to detect repeated work
Form a local transaction with the JMS Server limited to receipt and send of message
Form a new/separate local transaction with database commands
Leverage the completion status of the database to commit the JMS transaction
ResourceThe actual (e.g., database) target of a command with the transaction
Local TransactionA transaction involving only a single resource
Distributed TransactionA transaction involving two or more resources
Two-Phase CommitA protocol used to implement a distributed transaction
Long-lived TransactionsTransaction-like construct that spans long lengths of time and usually uses compensating transactions for rollback
Compensating TransactionA set of follow-up actions performed outside of the resource to return to a prior state when transaction rollback not available
Transaction Context PropagationSharing of the same transaction context across components
DeadlockWhen two or more threads own locks within a resource that the other thread requires to complete their transaction
EJB requires support of the JTA APIs
Interface specification between participants in a transaction
applications
resource managers
application server
EJB is primarily a transaction framework/platform for application code
Two styles of transaction demarcation
Container-Managed Transactions (declarative)
Bean Managed Transactions (programmatic)
Container and server handle all interaction with resources -- regardless of demarcation style
EJB transactions are flat -- not nested
Declarative interface to transactions
Declarative attributes tell container to execute a method
within a transaction (MANDATORY, REQUIRED, REQUIRES_NEW, SUPPORTS)
without a transaction (SUPPORTS, UNSUPPORTED, NEVER)
Figure 100.4. Container-Managed Transactions
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
public class HotelMgmtEJB implements HotelMgmtRemote, HotelMgmtLocal {
...
@PersistenceContext(unitName="ejbjpa-hotel")
private EntityManager em;
private HotelDAO dao;
private HotelMgmt hotelMgmt;
@PostConstruct
public void init() {
dao = new JPAHotelDAO();
((JPAHotelDAO)dao).setEntityManager(em);
hotelMgmt = new HotelMgmtImpl();
((HotelMgmtImpl)hotelMgmt).setHotelDao(dao);
}
@Override
@TransactionAttribute(TransactionAttributeType.SUPPORTS)
public Room getRoom(int number) {
return hotelMgmt.getRoom(number);
}
@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public Guest checkIn(Guest guest, Room room) throws RoomUnavailableExcepton {
return hotelMgmt.checkIn(guest, room);
}
Programmatic interface to transactions
Interactions through
javax.transaction.UserTransactioninterfaceEverything between utx.begin() and utx.commit() is within a single transaction
Figure 100.5.
@Singleton
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class HotelInitEJB implements HotelInitRemote {
@PersistenceUnit(unitName="ejbjpa-hotel")
private EntityManagerFactory emf;
@Resource
private UserTransaction tx;
@Override
public void clearAll() {
EntityManager em=emf.createEntityManager();
try {
JPAHotelDAO dao = new JPAHotelDAO();
dao.setEntityManager(em);
tx.begin();
em.joinTransaction(); //tells the EM to join the JTA UTx we are managing
dao.clearAll();
tx.commit();
} catch (Exception ex) {
try {
tx.rollback();
} catch (Exception ex2) {
throw new EJBException(ex2);
}
} finally {
if (em!=null) { em.close(); }
}
}