edocs Home > Oracle WebLogic Server Documentation > Administration Console Online Help > Servers: Configuration: Services
Servers: Configuration: Services
Configuration Options Related Tasks Related Topics
This page allows you to set WebLogic service configuration settings that are specific to this server.
Configuration Options
Name Description Enable Default Connection Factories Whether this server uses JMS default connection factories.
WebLogic Server provides the following JMS default connection factories:
weblogic.jms.ConnectionFactoryweblogic.jms.XAConnectionFactoryAn 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.JMSDefaultConnectionFactoriesEnabledJMS 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:
0Maximum value:
65534Changes 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.MessagingBridgeThreadPoolSizeMinimum value:
-1Maximum value:
65534Changes 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.XMLRegistryChanges 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.XMLEntityCacheChanges 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-WriteDirect I/O is supported on most platforms. For a potential performance boost, file stores in direct I/O mode will automatically load a 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.DisabledTransactions 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-FlushTransactions 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.
