Are MDBs really short-lived even with pooling?

109 Views Asked by At

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?

1

There are 1 best solutions below

2
Leonardo On BEST ANSWER

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.

Relatively short lived

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:

Can be long-lived (lives as long as the data in the database). The entity and its primary key survive the crash of the EJB container.

If the state of an entity was being updated by a transaction at the time the container crashed, the entity’s state is restored to the state of the last committed transaction when the entity is next retrieved.

So obviously the phrases are meant for comparison between entity and session objects. So, to reassume:

  • A session object. (Relatively short-lived)
  • A message-driven object. (Relatively short-lived)
  • An entity object. (Can be long-lived)