MDB Failure Handling: Difference between revisions
| Line 25: | Line 25: | ||
What happens with the MDB instance? | What happens with the MDB instance? | ||
The MDB instance that triggered the failure is destroyed. The @PreDestroy callback, if exists, is invoked, and the instance is | 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== | ==Message Delivery Occurs in a Non-Transactional Context== | ||
Revision as of 14:51, 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
What happens with the message?
What happens with the transaction?
What happens with the MDB instance?
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.