I was a bit surprised to find a line in Oracle docs, stating that MDBs are relatively short-lived:
Message-driven beans have the following characteristics.
- They execute upon receipt of a single client message.
- They are invoked asynchronously.
- They are relatively short-lived.
- They do not represent directly shared data in the database, but they can access and update this data.
- They can be transaction-aware.
- They are stateless.
http://docs.oracle.com/javaee/6/tutorial/doc/gipko.html#gipmj
What could this really mean taking that MDBs are expected to be pooled? Is there any specific reason to construct/destruct these more often than stateless session beans?
The message driven pool can be configured. The main concern for configuring the MDB pool is message arrival rate.
MDB are different from Stateless, in a sense that they are meant to listen messages do the job and go back dormant. Stateless on the other side stays in front of business layer listening from request coming from presentation/web layer which means a much heavy user load.
My guess is that each EJB is associated with a thread, which means that the container is reserving some resource for it. When the container needs resource, the choice is in theory to cut MDB rather than Stateless.
[UPDATE]
I have to correct myself, if you read the specification the same phrase Relatively short lived is reported even for session object (Steteless/Stateful). While entities are detailed as long lived:
So obviously the phrases are meant for comparison between entity and session objects. So, to reassume: