Declarative interface to transactions
Declarative attributes tell container to execute a method
within a transaction (MADATORY, REQUIRED, REQUIRES_NEW, SUPPORTS)
without a transaction (SUPPORTS, UNSUPPORTED, NEVER)
Container completes transaction protocol prior to marshaling return objects
Container must suspend any active transaction
When called with transaction active:
Caller transaction suspended during call
Caller transaction resumed after call
Caller transaction is not impacted by resource managers used during call
Caller transaction not passed to anything this method calls
Container must invoke method with transaction active
When called with transaction active:
Caller transaction context passed to method (unless @Asynchronous)
Caller transaction context passed to anything this method calls
Resource manager(s) called by method are enlisted in caller's transaction context
When called without transaction active:
New transaction started
Transaction committed after method returns
Container can invoke method with transaction either active or inactive
When called with transaction active:
Caller transaction context passed to method (unless @Asynchronous)
When called without transaction active:
No transaction started
Container must invoke method with new transaction active
New transaction started
Transaction committed after method returns and prior to returning result to client
When called with transaction active:
Caller transaction suspended during call
Caller transaction resumed after call
Caller transaction is not impacted by resource managers used during call
Caller transaction not passed to anything this method calls
Caller must already have transaction active
When called with transaction active:
Caller transaction context passed to method
When called without transaction active:
javax.ejb.EJBTransactionRequiredException
getUserTransaction()
Returned instance can use used to demarcate transactions
Restricted to EJBs using bean-managed transactions
getRollbackOnly()
Tests whether current transaction is going to be rolled back at the end
Restricted to EJBs using container-managed transactions
setRollbackOnly()
Allows EJBs to trigger the current transaction to be rolled back at the end
Restricted to EJBs using container-managed transactions
Figure 101.11. Example: Explicit Rollback thru EJB/SessionContext
@Resource
private SessionContext ctx;
@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public Product createProductAndRollback(Product product) {
//create a product in the database
Product p=beanA.createProduct(product);
beanA.flush(); //here just to highlight the impact of the rollback
ctx.setRollbackOnly();
return p; //return the product even thow we are going to roll it back
}
Resources created/modified within the transaction -- including resources operated on by called EJBs -- will be rolled back.
Figure 101.12. Example: IT Client Triggers Rollback
Product product = warehouse.createProductAndRollback(new Product("thing", 6));
//since we did not throw an exception -- we get a normal return object
assertEquals("unexpected quantity for product", 6, product.getQuantity());
//since we setRollbackOnly() prior to the return -- our product will not be there
Product p2 = warehouse.getProduct(product.getId());
assertNull("unexpected/rolled back product found", p2);
Even though the application did not throw an exception and gracefully returned a result -- the IT test shows the entity was not stored during the callback
No automatic rollback by default
Checked exceptions, but default, do not trigger rollbacks
Figure 101.14. Example: EJB Method Commits Data, Throws Checked Exception
@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public Product createProductAndThrowChecked(Product product)
throws MyCheckedProductException {
//create a product in the database
Product p=beanA.createProduct(product);
//throw a checked exception -- the product will still be committed
throw new MyCheckedProductException(p, "planned checked exception");
}
An error in processing can be reported with an exception without rollback
Figure 101.15. Example: Client Triggers Exception and Verifies Data Committed
Product product = null;
try {
warehouse.createProductAndThrowChecked(new Product("thing", 6));
fail("planned exception not thrown");
} catch (MyCheckedProductException ex) {
//the *checked* exception contains the product in the exception
product = ex.getProduct();
assertEquals("unexpected quantity for product", 6, product.getQuantity());
}
//our product should exist
Product p2 = warehouse.getProduct(product.getId());
assertEquals("product not updated async", 6, p2.getQuantity());
IT test verifies entity thrown with the exception was persisted
Checked/Application exceptions can be configured to trigger a rollback
Annotation tells container to automatically rollback transaction if thrown
Figure 101.17. Example: EJB Method Throws Checked Exception to Automatically Rollback
@Override
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public Product createProductAndThrowCheckedRollback(Product product) throws MyCheckedRollbackProductException {
//create a product in the database
Product p=beanA.createProduct(product);
beanA.flush(); //here just to highlight the impact of the rollback
//throw a checked exception marked for rollback -- the product will *NOT* be committed
throw new MyCheckedRollbackProductException(p, "planned checked exception");
}
An error in processing can be reported with an exception without rollback
Figure 101.18. Example: Client Triggers Exception and Verifies Data Committed
Product product = null;
try {
warehouse.createProductAndThrowCheckedRollback(new Product("thing", 6));
fail("planned exception not thrown");
} catch (MyCheckedRollbackProductException ex) {
//the *checked* exception contains the product in the exception
product = ex.getProduct();
assertEquals("unexpected quantity for product", 6, product.getQuantity());
}
//since we used a rollback=true checked exception -- our product will not be there
Product p2 = warehouse.getProduct(product.getId());
assertNull("unexpected/rolled back product found", p2);
IT test verifies entity thrown with the exception was persisted
