web server - Borland Technical Publications

Clustering of MDBs
This is yet another simple element. It's value is essentially identical to the value of the
element found within the declaration discussed above.
Now our XML looks like the following:
MyMDBTopic
...
serial://resources/tcf
serial://resources/tcf
...
Note
Once deployed, you can access datasources from the MDB MyMDBTopic.
The connection factory objects are much like JDBC datasources and the names of
topics and queues are similar to specifying a database table name. The connection
factory objects themselves are typed, for example TopicConnectionFactory and
QueueConnectionFactory, depending upon what you are listening for. Furthermore, each
of subtype of XA flavor is are needed when global transactions are in effect. In the
typical development environment, there is only one JMS service provider, so only a
pair of connection factories are required: one for topics and one for queues. Go to
Chapter 23, “Using JMS” for detailed information on configuring these.
You must use an XA connection factory when the MDB is deployed with the REQUIRED
transaction attribute. The whole idea of this deployment is to enable the consumption
of the message that drives the MDB to share the same transaction as any other work
that is done from within the MDB.onMessage() method. To achieve this the container
performs XA coordination with the JMS service provider and any other resources
enlisted in the transaction.
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 trade-off for this optimal loadbalancing
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.
186 BES Developer’s Guide