Message-driven beans (MDBs) are stateless, server-side, transaction-aware components for processing asynchronous JMS messages.
One of the most important aspects of MDBs is that they can consume and process messages concurrently.
This capability provides a significant advantage over traditional JMS clients, which must be custom-built to manage resources, transactions, and security in a multithreaded environment.
Just as the session beans have well-defined life cycles, so does the MDB bean. The MDB instance’s life cycle is pretty much the same as the stateless bean. In fact, it’s divided in two states: Does not Exist and Method ready Pool.
When a message is received, the EJB container checks to see if any MDB instance is available in the pool. If a bean is available in the free pool, JBoss uses that instance.
After an MDB instance’s onMessage() method returns, the request is complete, and the instance it is placed back in the free pool. This results in the best response time, as the request is served without waiting for a new instance to be created.
If no bean instances are handy, the container checks if there is room for more MDB in the pool by comparing the MDB’s MaxSize attribute with the pool size.
If MaxSize still has not been reached, a new MDB is initialized. The creation sequence, as pointed out in the image, is just the same as stateless bean. Failure to create a new instance, on the other hand, will imply that the request will be blocked until an active MDB completes. If the request cannot acquire an instance from the pool within the instance-acquisition-timeout, an exception is thrown
The configuration of the MDB pool is exactly the same as for the SLSB, so we will just include it here without further explanations
Applications with business processes, which are dependent on periodic notifications, can use the EJB 3 Timer service that provides a way to allow methods to be invoked at specific times or time intervals.
The EJB Timer service can be attached to any EJB 3 type, except for Stateful session beans and requires as little as setting a method marked with the
@javax.ejb.Timeout annotation, which will be triggered by the container when the time interval expires.
The following example shows how to implement a very simple timer, which will be set on the client side by invoking the scheduleTimer(long milliseconds)
As far as it concerns the configuration, you can define the data-store path, that is temporary file system path where planned executions are stored and the amount of threads to reserve to the timer service with the thread-pool-name attribute, which needs to reference a thread-pool element: