user manual

Chapter 20: Message-Driven Beans and JMS 217
Clustering of MDBs
Clustering of MDBs
The clustering of MDBs differs from the clustering of other enterprise beans.
With MDBs, producers put messages into a destination. The messages will
reside in the destination until a consumer takes the messages off the
destination (or, if the messages are non-durable, when the server hosting the
destination crashes). This is a pull model since the message will just reside on
the destination until a consumer asks for it. The containers contend to get the
next available message on the destination. MDBs provide an ideal load-
balancing paradigm, one that is smoother than other enterprise bean
implementations for distributing a load . The server that is the least burdened
can ask for and obtain the message. The tradeoff for this optimal load-
balancing is that messaging has extra container overhead by virtue of the
destination's position between the producer and the consumer.
There is not, however, the same concept of failover with a messaging service
as exists in VisiBroker. If the consumer disappears, the queue fills up with
messages. As soon as the consumer is brought back online, the messages
resume being consumed. Of course, the JMS server itself should be fault-
tolerant. The client should never notice any "failure" with the exception of
response delays if such messages are expected. This kind of fault tolerance
demands only a way of detecting failed consumers and activating them after
failure. If you have the Borland Deployment Operations System (BDOC)
installed and running, it will automatically maintain the desired state of its
clustered services under active management.
That said, it is possible to deploy MDBs in more than one Partition with the
Messaging Server pushing messages to only one, switching to the other in
case of failure. Most JMS products allow queues to behave in load-balancing
or fault-tolerant modes. That is, MDB replicas can register to the same queue
and the messages are distributed to them using a load-balancing algorithm.
Alternately, messages may all go to one consumer until it fails, at which point
delivery shifts to another. The connection established to the JMS service
provider from the MDB can also provide a load-balancing and/or fault-tolerant
node. JMS service providers may provide fault-tolerance features. For specific
information on clustering and fafaultolerance features, refer to Chapter 24,
“JMS provider pluggability”..
Keep in mind that only one MDB instance in a container that subscribes to a
topic will consume any given message. This means that, for all parallel
instances of an MDB to concurrently process messages, only one of the
instances will actually receive any particular message. This frees up the other
instances to process other messages that have been sent to the topic. Note
that each container that binds to a particular topic will consume a message
sent to that topic. The JMS subsystem will treat each message-driven bean in
separate containers as a separate subscriber to that message! This means
that if the same MDB is deployed to many containers in a cluster, then each
deployment of the bean will consume a message from the topic to which it
subscribes. If this is not the behavior you desire, and you require exactly one