MDB Failure Handling: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 19: Line 19:
==Message Delivery Occurs in a Container-Managed Transactional Context==
==Message Delivery Occurs in a Container-Managed Transactional Context==


What happens with the message?
If the message  


What happens with the transaction?
The current transaction is automatically rolled back. The MDB container's transactional interceptor catches the RuntimeException and rolls back the transaction, by invoking <tt>javax.transaction.Transaction.setRollbackOnly()</tt>.
 
The transactional interceptor catches the RuntimeException and rolls back the transaction, by invoking <tt>javax.transaction.Transaction.setRollbackOnly()</tt>.


The MDB instance that triggered the failure is destroyed. The @PreDestroy callback, if exists, is invoked, and the instance is discarded from the pool. Upon re-delivery, if any, a new instance to handle the message will be created.
The MDB instance that triggered the failure is destroyed. The @PreDestroy callback, if exists, is invoked, and the instance is discarded from the pool. Upon re-delivery, if any, a new instance to handle the message will be created.

Revision as of 14:56, 25 April 2017

Internal

Relevance

EAP 6.4.10

Overview

This article addresses failure handling in an MDB context. It was written while experimenting with EAP 6.4 and a HornetQ-based messaging subsystem.

Failure Handling Specification

JSR 318 Enterprise JavaBeans Version 3.1 EJB Core Contract and Requirements, Section 5.4.18 "Dealing with Exceptions" mentions that MDBs should not throw RuntimeExceptions. If a RuntimeExceptions occurs, the container will transition the MDB in the "does not exist" state. The message will not be acknowledged, and if messages arrive to the destination, the container can delegate the message to another MDB instance.

WildFly/HornetQ Behavior on RuntimeException

Message Delivery Occurs in a Container-Managed Transactional Context

If the message

The current transaction is automatically rolled back. The MDB container's transactional interceptor catches the RuntimeException and rolls back the transaction, by invoking javax.transaction.Transaction.setRollbackOnly().

The MDB instance that triggered the failure is destroyed. The @PreDestroy callback, if exists, is invoked, and the instance is discarded from the pool. Upon re-delivery, if any, a new instance to handle the message will be created.

Message Delivery Occurs in a Non-Transactional Context

How to Indicate Failure in a Transactional Context

How to Indicate Failure in a Non-Transactional Context