4 Deploying MDBs
This chapter includes the following sections:
Destination and MDBs: Collocation vs. non-Collocation
Collocated Destination/MDBs
You cannot collocate the MDB and the JMS destination if you use a third-party JMS provider that cannot run on Oracle WebLogic Server, such as MQ Series.
Figure 4-1 and Figure 4-2 illustrate architectures in which the MDB application is deployed to the server instance that hosts the associated JMS destination. These architectures vary in that the first has a distributed destination and the second does not. In an application that uses distributed destinations, the MDB is deployed to each server instance that hosts a member of the distributed destination set. For more information about distributed destinations, see JMS Distributed Destinations. As illustrated in Figure 4-1 the message "M1" is delivered to an instance of MDB_A on each server instance where a distributed destination and MDB_A are deployed. Figure 4-1 illustrates a One-Copy-Per-Server
topic message distribution mode pattern. Topic patterns are discussed in more detail in Setting topicMessagesDistributionMode.
Figure 4-1 Collocated Destination/MDBs, Distributed Topic, One-Copy-Per-Server Pattern
![Description of Figure 4-1 follows Description of Figure 4-1 follows](img/cluster3.png)
Description of "Figure 4-1 Collocated Destination/MDBs, Distributed Topic, One-Copy-Per-Server Pattern"
Figure 4-2 Collocated Destination/MDBs, Non-Distributed Destination
![Description of Figure 4-2 follows Description of Figure 4-2 follows](img/cluster1.png)
Description of "Figure 4-2 Collocated Destination/MDBs, Non-Distributed Destination"
Non-Collocated Destination/MDBs
Figure 4-3 illustrates an architecture in which an MDB runs on a different server instance from the JMS Destination to which the MDB listens.
Figure 4-3 Non-Collocated Application, Non-Distributed Destination
![Description of Figure 4-3 follows Description of Figure 4-3 follows](img/cluster2.png)
Description of "Figure 4-3 Non-Collocated Application, Non-Distributed Destination"
Running your MDBs on a different server instance from the JMS Destination to which the MDB listens is suitable if:
-
Your application uses a third-party JMS provider, such as MQ Series.
-
You want to isolate application code (the MDBs) from the JMS infrastructure. By placing JMS destinations and MDBs on separate server instances, you prevent application problems—for example, MDBs consuming all of your virtual machine's memory—from interrupting the operation of the JMS infrastructure.
-
Your MDB application is very CPU-intensive. On a separate machine, your application can use 100 percent of the CPU without affecting the operation of the JMS infrastructure.
-
One machine in your configuration has more processing power, disk space, and memory than other machines in the configuration.
The JMS destination and MDBs could also be deployed on non-clustered servers, servers within the same cluster, or to servers in separate clusters.
Note:
WebLogic Server does not support non-collocated Destination/MDBs in a cluster when you deploy the destination on a target that can be migrated.JMS Distributed Destinations
If you configure a distributed destination, WebLogic JMS distributes the messaging load across available members of the distributed destination. If a member of the destination becomes unavailable due to a server failure, message traffic is re-directed to the other available physical destinations in the distributed destination set. You control whether an MDB that accesses a WebLogic distributed queue in the same cluster consumes from all distributed destination members or only those members local to the current Oracle WebLogic Server, using the distributed-destination-connection
element in the weblogic-ejb-jar.xml
file or the distributedDestinationConnection
annotation. Similarly, this setting controls behavior for some topic MDB scenarios, as described in Configuring and Deploying MDBs Using JMS Topics, and Topic Deployment Scenarios.
If you deploy an MDB and the associated distributed queue to the same cluster, Oracle WebLogic Server automatically enumerates the distributed queue members and ensures that each member is serviced by at least one MDB pool. For distributed queues, there will be one MDB pool for each local member when distributedDestinationConnection
is LocalOnly
(the default); otherwise, for queues, when distributedDestinationConnection
is set to EveryMember
, each Oracle WebLogic Server instance creates multiple local MDB pools - one for each local member plus one for each remote member.
If you deploy an MDB and its associated queue to different clusters, Oracle WebLogic Server automatically enumerates the distributed queue members and ensures that each member is serviced by an MDB pool on each server in the MDB cluster. For example, if the distributed queue has three members, each JVM in the MDB cluster will create three MDB pools.
For more information about distributed topics, see Configuring and Deploying MDBs Using JMS Topics.
Best Practice
WebLogic clustering and WebLogic JMS distributed destinations increase scalability and high availability. Examine some of the best practices to increase scalability and high availability.
Oracle recommends that the machines that host a cluster have identical or similar processing power, disk space, and memory to ensure well-load-balanced message processing. Similarly, it is recommended that the Oracle WebLogic Server instances in a particular WebLogic cluster have homogenous JMS configuration and MDB deployments.
For an example, see Figure 4-1. For additional information about distributed destinations, see Using Distributed Destinations in Developing JMS Applications for Oracle WebLogic Server.