Using Partitioned Distributed Topics Accessing Distributed Destination Members Distributed Destination Failover

Using Distributed Destinations 9-7

9.5.2.3 Deploying Message-Driven Beans on a Distributed Topic

For information on how to deploy MDBx on topics, see Configuring and Deploying MDBs Using Distributed Topics in Programming Message-Driven Beans for Oracle WebLogic Server.

9.5.3 Using Partitioned Distributed Topics

Starting in WebLogic Server 10.3.4.0, partitioned distributed topics, combined with the ability to share subscriptions and allow multiple connections to use the same Client ID, provide the following application design patterns that provide parallel processing and HA capabilities similar to distributed queues: ■ One-copy-per-instance: Each instance of an application gets one copy of each message that is published to the Topic. ■ One-copy-per-application: Each application as a whole that is all instances of the application together receives one copy of each message that is published to the DT. That is each instance only receives a subset of the messages that are sent to the DT. For more information on using Partitioned Distributed Topics, see Section 13, Developing Advanced PubSub Applications.

9.5.4 Accessing Distributed Destination Members

For information on how to access distributed destinations and their members, see Section C, How to Lookup a Destination.

9.5.5 Distributed Destination Failover

A simple way to failover a client connected to a failed distributed destination is to write reconnect logic in the client code to connect to the distributed destination after catching onException. Note: Oracle recommends designing applications that utilize WebLogic Server MDBs. See Configuring and Deploying MDBs Using Distributed Topics in Programming Message-Driven Beans for Oracle WebLogic Server for detailed information on how to design and implement applications that use message-driven beans to provide improved HA and scalability. Note: If the distributed queue member on which a queue producer is created should fail, yet the WebLogic Server instance where the producers JMS connection resides is still running, the producer remains alive and WebLogic JMS will fail it over to another distributed queue member, irrespective of whether the Load Balancing option is enabled. For example, a WebLogic cluster contains WLSServer1, WLSServer2, and WLSServer3 and you are connected to WLServer2. If server WLSServer 2 fails, WebLogic JMS fail the producer over to one of the remaining cluster members. For more information, see Configuring Distributed Destination Resources in Configuring and Managing JMS for Oracle WebLogic Server. 9-8 Programming JMS for Oracle WebLogic Server

9.6 Using Message-Driven Beans with Distributed Destinations

A message-driven bean MDB acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. For more information on MDBs, see: ■ MDBs and Messaging Models in Oracle Fusion Middleware Programming Message-Driven Beans for Oracle WebLogic Server ■ Deploying MDBs in Oracle Fusion Middleware Programming Message-Driven Beans for Oracle WebLogic Server

9.7 Common Use Cases for Distributed Destinations

The following sections provide common use case scenarios when using distributed destinations: ■ Section 9.7.1, Maximizing Production ■ Section 9.7.2, Maximizing Availability ■ Section 9.7.3, Stuck Messages

9.7.1 Maximizing Production

To maximize message production, Oracle recommends that each member of a distributed destination be associated with a producer and a consumer. The following diagram demonstrates how to efficiently provide maximum message production and high availability using a UDD without using load balancing: Figure 9–1 Paired Producers and Consumers In this situation, UDD1 is a uniform distributed destination composed of two physical members: D1 and D2. Each physical destination has a producerconsumer pair and the effective path for a message follows the solid line from the producer through the destination member to the consumer. If you are using ordering, you should have a producer for each expected Unit-of-Order. See Section 10.5.4, Using Unit-of-Order with Distributed Destinations.