Lifecycle of an MDB
When a message arrives into a queue, the container retrieves it, starts a transaction, and assigns a MDB instance from the pool to service it.
The sequence of events is as follows:
- A message is delivered to a JMS session listener
- An idle MDB is pulled out of the pool.
MessageDrivenContextis injected into the bean
- The container executes the
onMessagemethod of the bean, passing in the actual message.
- When the
onMessagemethod finishes executing, the bean is pushed back into the idle-ready pool.
minSession config property means that the application server should ensure that there are always the given number of instances of the MDB in the pool, in the method-ready state.
Key facts about MDBs
In a queue-based JMS application (point-to-point model), each MDB instance has its own (JMS) session.
In a topic-based JMS application (the publish/subscribe model), all local instances of an MDB share a JMS session. A given message is distributed to multiple MDBs—one copy to each subscribing MDB. If multiple MDBs are deployed to listen on the same topic, then each MDB receives a copy of every message. A message is processed by one instance of each MDB that listens to the topic.