Suppose I have a session bean that implements a REQUIRED transaction method:
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void doTransaction() throws Exception {
try {
...
// call to non-EJB bean object (not session, stateless or entity bean)
} catch (Exception e) {
context.setRollbackOnly();
throw e;
}
}
Suppose doTransaction() changes the internal state of the non-bean object, and fails. Does the rollback restore the original state of the non-bean? If not, what would be the recommanded way to handle such a case? (or are POJO calls within a transaction not allowed?)
The rollback that EJB automatically does after e.g. an exception is thrown, will only affect resources that have joined the ongoing (JTA) transaction.
There are a couple of ways to join such a transaction. The most complete way is by implementing the XAResource interface and letting your code enlist that implementation. A simpler, but less powerful way is to use a Synchronizer.
Strictly speaking, neither the EJB container or transaction manager itself rollbacks anything. Instead, it gives the enlisted resources an opportunity to do such rollback. Thus, it will never by itself be able to restore previous values of random variables that happen to have been modified during a transaction.
For completeness, the resources that are typically (automatically) enlisted in a transaction are database connections (if they come from a container managed datasource), JMS messages (again, if the destination is container managed), (distributed) caches, and JCA based EIS resources.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With