Administration Console Online Help

Previous Next Open TOC in new window
Content starts here

Servers: Configuration: Services

Configuration Options     Related Tasks     Related Topics

Use this page to set WebLogic service configuration settings that are specific to this server.

Configuration Options

Name Description
Enable Default Connection Factories

Specifies whether this server uses JMS default connection factories.

WebLogic Server provides the following JMS default connection factories:

  • weblogic.jms.ConnectionFactory
  • weblogic.jms.XAConnectionFactory

    An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions. All other preconfigured attributes for the default connection factories are set to the same default values as a user-defined connection factory. If the preconfigured settings of the default factories are appropriate for your application, you do not need to configure any additional factories for your application.

Note: When using the default connection factories, you have no control over targeting the WebLogic Server instances where the connection factory may be deployed. However, you can disable the default connection factories on a per-server basis. To deploy a connection factory on independent servers, on specific servers within a cluster, or on an entire cluster, you need to configure a connection factory and specify the appropriate server targets.

MBean Attribute:
ServerMBean.JMSDefaultConnectionFactoriesEnabled

JMS Thread Pool Size

The size of the JMS execute thread pool.

Note: Incoming RMI calls execute in the JMS execute queue/thread pool, if one exists; otherwise, they execute in the default execute queue.

Additional executes (work that cannot be completed in the initial RMI thread) are executed in the default execute queue.

The difference in setting up a JMS-specific thread pool is that JMS will not be starved by other execute threads and vice versa.

Minimum value: 0

Maximum value: 65534

Changes take effect after you redeploy the module or restart the server.

Bridge Thread Pool Size

Returns the size of the messaging bridge execute thread pool.

MBean Attribute:
KernelMBean.MessagingBridgeThreadPoolSize

Minimum value: -1

Maximum value: 65534

Changes take effect after you redeploy the module or restart the server.

XML Registry

The server's XML registry, which is used to configure the behavior of JAXP (Java API for XML Parsing).

MBean Attribute:
ServerMBean.XMLRegistry

Changes take effect after you redeploy the module or restart the server.

XML Entity Cache

The server's XML entity cache, which is used to configure the behavior of JAXP (Java API for XML Parsing).

MBean Attribute:
ServerMBean.XMLEntityCache

Changes take effect after you redeploy the module or restart the server.

Directory

The path name to the file system directory where the file store maintains its data files.

When targeting a file store to a migratable target, the store directory must be accessible from all candidate server members in the migratable target. For highest availability, use either a SAN (Storage Area Network) or a dual-ported SCSI disk.

Changes take effect after you redeploy the module or restart the server.

Synchronous Write Policy

The disk write policy that determines how the file store writes data to disk.

This policy also affects the JMS file store's performance, scalability, and reliability. The valid policy options are:

  • Direct-Write

    Direct I/O is supported on all platforms. When available, file stores in direct I/O mode automatically load the native I/O wlfileio2 driver. This driver is available on Windows, Solaris, HP, AIX, and Linux platforms. To view a running file store's synchronous write policy and driver, check the BEA-280050 message in the server log.

  • Disabled

    Transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This policy is the fastest, but the least reliable (that is, transactionally safe). It can be more than 100 times faster than the other policies, but power outages or operating system failures can cause lost and/or duplicate messages.

  • Cache-Flush

    Transactions cannot complete until all of their writes have been flushed down to disk. This policy is reliable and scales well as the number of simultaneous users increases.

Related Tasks

Related Topics


Back to Top