Servers: Configuration: Services
Configuration Options Related Tasks Related Topics
Use this page to set WebLogic service configuration settings that are specific to this server.
Name Description Enable Default Connection Factories
Specifies whether this server uses JMS default connection factories.
WebLogic Server provides the following JMS default connection factories:
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.
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.
Bridge Thread Pool Size
Returns the size of the messaging bridge execute thread pool.
The server's XML registry, which is used to configure the behavior of JAXP (Java API for XML Parsing).
XML Entity Cache
The server's XML entity cache, which is used to configure the behavior of JAXP (Java API for XML Parsing).
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.
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 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
wlfileio2driver. 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.
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.
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.
- Configure connection factories
- Modify the Default Store Settings
- Manage a messaging bridge
- Configure XML Resources