I have servlet calling an EJB (MessageServiceImpl), which calls another EJB (MessageRegistry) that performs a database lookup using JPA. When there is a JPA failure, an exception is thrown. I want to catch the exception, and raise an alarm indicating that there was a failure (which fires an SNMP trap), and then have the exception handled normally. The alarm management is handled by another EJB (ManagementServiceImpl).
The issue that I am having is that after the JPA failure, the transaction associated with this processing has been marked as rolled-back, and the attempt to call the ManagementService EJB, results in an EJBTransactionRolledbackException being thrown (since it normally wouldn't make sense to continue processing if the transaction is over-with).
I could probably use a org.eclipse.persistence.exceptions.ExceptionHandler to catch the failure before the container rolls-back the transaction and raise an alarm there, but there would not be enough information to actually determine what type of application processing was being done (for example - how would it determine the the error was associated with looking up a message from the Message Registry).
Any ideas on what approach might be able to use to be able to call the ManagementService EJB after a JPA failure?
Can't you specify that either class ManagementServiceImpl or method ManagementServiceImpl.raiseAlarm runs either with no transaction (@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)) or a new transaction (@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)?