3-10 Configuring and Managing JMS for Oracle WebLogic Server
Also, using default connection factories means that you have no control over targeting the WebLogic Server instances where the connection factory may be deployed.
However, you can enable and or disable the default connection factories on a per-WebLogic Server basis, as defined in Server: Configuration: Services in the Oracle
WebLogic Server Administration Console Help.
3.6.2 Connection Factory Configuration Parameters
The WebLogic Server Administration Console enables you to configure, modify, target, and delete connection factory resources in a system module. For a road map of
the JMS connection configuration tasks, see Configure connection factories in the Oracle WebLogic Server Administration Console Help.
You can modify the following parameters for connection factories:
■
General configuration parameters, including modifying the default client parameters, default message delivery parameters, load balancing parameters,
unit-of-order parameters, and security parameters.
■
Transaction parameters, which enable you to define a value for the transaction time-out option and to indicate whether an XA queue or XA topic connection
factory is returned, and whether the connection factory creates sessions that are JTA aware.
■
Flow control parameters, which enable you to tell a JMS server or destination to slow down message producers when it determines that it is becoming overloaded.
Some connection factory options are dynamically configurable. When options are modified at runtime, only incoming messages are affected; stored messages are not
affected. For more information about the default values for all connection factory options, see JMSConnectionFactoryBean in the Oracle WebLogic Server MBean
Reference.
3.6.3 Connection Factory Targeting
You can target connection factories to one or more JMS server, to one or more WebLogic Server instances, or to a cluster.
■
JMS servers — You can target connection factories to one or more JMS servers along with destinations. You can also group a connection factory with standalone
queues or topics in a subdeployment targeted to a specific JMS server, which guarantees that all these resources are co-located to avoid extra network traffic.
Another advantage of such a configuration would be if the targeted JMS server needs to be migrated to another WebLogic server instance, then the connection
Note: Oracle recommends using custom connection factories instead
of default connection factories because default connection factories are not tunable. Custom connection factory tunables often prove useful
for tuning applications even after the application is in production.
Note:
When selecting the XA Connection Factory Enabled option to enable JTA transactions with JDBC stores, you must verify that the
configured JDBC data source uses a non-XA JDBC driver. This limitation does not remove the XA capabilities of layered subsystems
that use JDBC stores. For example, WebLogic JMS is fully XA-capable regardless of whether it uses a file store or any JDBC store.
Configuring Basic JMS System Resources 3-11
factory and all its connections will also migrate along with the JMS servers destinations. However, when standalone queues or topics are members of a
subdeployment, a connection factory can only be targeted to the same JMS server.
■
Weblogic server instances — To establish transparent access to JMS destinations from any server in a domain, you can target a connection factory to multiple
WebLogic Server instances simultaneously.
■
Cluster — To establish cluster-wide, transparent access to JMS destinations from any server in a cluster, you can target a connection factory to all server instances in
the cluster, or even to specific servers within the cluster.
For more information on JMS system module subdeployment targeting, see Section 3.5.1, JMS System Module and Resource Subdeployment Targeting.
For information on connection factory targeting best practices, see
Section 9.2, Targeting Best Practices.
3.7 Queue and Topic Destination Configuration
