![]() ![]() ![]() ![]() |
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. The default Java EE 7 JMS Connection Factory, java:comp/DefaultJMSConnectionFactory, will be available even when the WebLogic JMS default connection factories are disabled.
MBean Attribute:
ServerMBean.JMSDefaultConnectionFactoriesEnabled
Connection Factory Unmapped Resource Reference Mode Use this unmapped resource reference mode to specify the behavior of any resource reference to a Connection Factory when the resource reference does not directly specify a JNDI name by a lookup attribute, or by a mappedName attribute, or by a jndi-name in a descriptor file. If a JNDI name is specified, the resource reference either resolves to the specified object in the JNDI tree or generates a javax.naming.NameNotFoundException.
Following are the available unmapped resource reference modes:
FailSafe :
In this mode, an application JMS connection factory resource reference that does not specify a JNDI name resolves to an object bound to the JNDI tree with the same name as the resource reference name if one can be found in JNDI tree. Otherwise, it throws a javax.naming.NameNotFoundException. A resource reference without a JNDI name never returns a Java EE 7 Default Connection Factory in this mode.
This mode yields pre-12.2.1 WebLogic Server behavior. This mode is Java EE compliant, but the Java EE 7 specification disallows it from being the default mode.
ReturnDefault :
This policy is a Java EE compliant mode and it is the default mode. It complies with Java EE 7 while doing a best effort to try delivering FailSafe behavior when it is expected.
(a) If the resource reference name matches the local JNDI name of a configured foreign JMS provider mapping, then WebLogic Server returns the remote JNDI entry from the mapping if it can be resolved, or it throws a javax.naming.NameNotFoundException.
(b) If the resource reference does not match with a foreign JMS provider mapping, and if the resource reference name matches the name of an object that is already bound to the JNDI tree, WebLogic Server returns the JNDI tree object.
(c) If neither (a) nor (b) apply, then WebLogic Server returns "java:comp/DefaultJMSConnectionFactory". In addition, it adds an 'Info' message in the server log indicating that a special behavior has occurred. This log message will occur at most once per application per server boot.
MBean Attribute:
ServerMBean.JMSConnectionFactoryUnmappedResRefMode
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 other reliable shared storage.
Use of NFS mounts is discouraged, but supported. Most NFS mounts are not transactionally safe by default, and, to ensure transactional correctness, need to be configured using your NFS vendor documentation in order to honor synchronous write requests.
For
SynchronousWritePolicy
ofDirect-Write-With-Cache
, see Cache Directory.Additional O/S tuning may be required if the directory is hosted by Microsoft Windows, see Synchronous Write Policy for details.
MBean Attribute:
DefaultFileStoreMBean.Directory
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. Oracle recommends
Direct-Write-With-Cache
which tends to have the highest performance. The default value isDirect-Write
. 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
wlfileio
driver. This option tends to out-performCache-Flush
and tend to be slower thanDirect-Write-With-Cache
. This mode does not require a native storewlfileio
driver, but performs faster when they are available.Direct-Write-With-Cache
Store records are written synchronously to primary files in the directory specified by the
Directory
attribute and asynchronously to a corresponding cache file in theCache Directory
. TheCache Directory
provides information about disk space, locking, security, and performance implications. This mode requires a native storewlfileiocode
driver. If the native driver cannot be loaded, then the write mode automatically switches toDirect-Write
. See Cache Directory.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.Transactionally safe but tends to be a lower performer than direct-write policies.
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 is the fastest policy because write requests do not block waiting to be synchronized to disk, but, unlike other policies, is not transactionally safe in the event of operating system or hardware failures. Such failures can lead to duplicate or lost data/messages. This option does not require native store
wlfileio
drivers, but may run faster when they are available. Some non-WebLogic JMS vendors default to a policy that is equivalent toDisabled
.Notes:
When available, file stores load WebLogic
wlfileio
native drivers, which can improve performance. These drivers are included with Windows, Solaris, Linux, and AIX WebLogic installations.Certain older versions of Microsoft Windows may incorrectly report storage device synchronous write completion if the Windows default
Write Cache Enabled
setting is used. This violates the transactional semantics of transactional products (not specific to Oracle), including file stores configured with aDirect-Write
(default) orDirect-Write-With-Cache
policy, as a system crash or power failure can lead to a loss or a duplication of records/messages. One of the visible symptoms is that this problem may manifest itself in high persistent message/transaction throughput exceeding the physical capabilities of your storage device. You can address the problem by applying a Microsoft supplied patch, disabling the WindowsWrite Cache Enabled
setting, or by using a power-protected storage device. See http://support.microsoft.com/kb/.NFS storage note: On some operating systems, native driver memory-mapping is incompatible with NFS when files are locked. Stores with synchronous write policies
Direct-Write-With-Cache
or Disabled, and WebLogic JMS paging stores enhance performance by using the nativewlfileio
driver to perform memory-map operating system calls. When a store detects an incompatibility between NFS, file locking, and memory mapping, it automatically downgrades to conventional read/write system calls instead of memory mapping. For best performance, Oracle recommends investigating alternative NFS client drivers, configuring a non-NFS storage location, or in controlled environments and at your own risk, disabling the file locks (See Enable File Locking). For more information, see "Tuning the WebLogic Persistent Store" in Tuning Performance of Oracle WebLogic Server.MBean Attribute:
DefaultFileStoreMBean.SynchronousWritePolicy
Cache Directory The location of the cache directory for
Direct-Write-With-Cache
, ignored for other policies.When
Direct-Write-With-Cache
is specified as theSynchronousWritePolicy
, cache files are created in addition to primary files (see Directory for the location of primary files). If a cache directory location is specified, the cache file path isCacheDirectory/WLStoreCache/StoreNameFileNum.DAT.cache
. When specified, Oracle recommends using absolute paths, but if the directory location is a relative path, thenCacheDirectory
is created relative to the WebLogic Server instance's home directory. If "" orNull
is specified, theCache Directory
is located in the current operating systemtemp
directory as determined by thejava.io.tmpdir
Java System property (JDK's default:/tmp
on UNIX,%TEMP%
on Windows) and isTempDirectory/WLStoreCache/DomainName/unique-id/ StoreNameFileNum.DAT.cache
. The value ofjava.io.tmpdir
varies between operating systems and configurations, and can be overridden by passing-Djava.io.tmpdir=My_path
on the JVM command line.Considerations:
Security: Some users may want to set specific directory permissions to limit access to the cache directory, especially if there are custom configured user access limitations on the primary directory. For a complete guide to WebLogic security, see "Securing a Production Environment for Oracle WebLogic Server."
Additional Disk Space Usage: Cache files consume the same amount of disk space as the primary store files that they mirror. See Directory for the location of primary store files.
Performance: For the best performance, a cache directory should be located in local storage instead of NAS/SAN (remote) storage, preferably in the operating system's
temp
directory. Relative paths should be avoided, as relative paths are located based on the domain installation, which is typically on remote storage. It is safe to delete a cache directory while the store is not running, but this may slow down the next store boot.Preventing Corruption and File Locking: Two same named stores must not be configured to share the same primary or cache directory. There are store file locking checks that are designed to detect such conflicts and prevent corruption by failing the store boot, but it is not recommended to depend on the file locking feature for correctness. See Enable File Locking.
Boot Recovery: Cache files are reused to speed up the File Store boot and recovery process, but only if the store's host WebLogic Server instance has been shut down cleanly prior to the current boot. For example, cache files are not re-used and are instead fully recreated: after a
kill -9
, after an OS or JVM crash, or after an off-line change to the primary files, such as a store admin compaction. When cache files are recreated, aWarning
log message 280102 is generated.Fail-Over/Migration Recovery: A file store safely recovers its data without its cache directory. Therefore, a cache directory does not need to be copied or otherwise made accessible after a fail-over or migration, and similarly does not need to be placed in NAS/SAN storage. A
Warning
log message 280102, which is generated to indicate the need to recreate the cache on the new host system, can be ignored.Cache File Cleanup: To prevent unused cache files from consuming disk space, test and developer environments should periodically delete cache files.
MBean Attribute:
DefaultFileStoreMBean.CacheDirectory
Minimum Window Buffer Size The minimum amount of data, in bytes and rounded down to the nearest power of 2, mapped into the JVM's address space per primary store file. Applies to synchronous write policies
Direct-Write-With-Cache
andDisabled
, but only when a nativewlfileio
library is loaded. See Maximum Window Buffer Size.MBean Attribute:
DefaultFileStoreMBean.MinWindowBufferSize
Minimum value:
-1
Maximum value:
1073741824
Maximum Window Buffer Size The maximum amount of data, in bytes and rounded down to the nearest power of 2, mapped into the JVM's address space per primary store file. Applies to synchronous write policies
Direct-Write-With-Cache
andDisabled
but only when the nativewlfileio
library is loaded.A window buffer does not consume Java heap memory, but does consume off-heap (native) memory. If the store is unable to allocate the requested buffer size, it allocates smaller and smaller buffers until it reaches
MinWindowBufferSize
, and then fails if cannot honorMinWindowBufferSize
.Oracle recommends setting the max window buffer size to more than double the size of the largest write (multiple concurrently updated records may be combined into a single write), and greater than or equal to the file size, unless there are other constraints. 32-bit JVMs may impose a total limit of between 2 and 4GB for combined Java heap plus off-heap (native) memory usage.
See store attribute
AllocatedWindowBufferBytes
to find out the actual allocated Window Buffer Size.MBean Attribute:
DefaultFileStoreMBean.MaxWindowBufferSize
Minimum value:
-1
Maximum value:
1073741824
IO Buffer Size The I/O buffer size, in bytes, automatically rounded down to the nearest power of 2.
For the
Direct-Write-With-Cache
policy when a nativewlfileio
driver is available,IOBufferSize
describes the maximum portion of a cache view that is passed to a system call. This portion does not consume off-heap (native) or Java heap memory.For the
Direct-Write
andCache-Flush
policies,IOBufferSize
is the size of a per store buffer which consumes off-heap (native) memory, where one buffer is allocated during run-time, but multiple buffers may be temporarily created during boot recovery.When a native
wlfileio
driver is not available, the setting applies to off-heap (native) memory for all policies (includingDisabled
).For the best runtime performance, Oracle recommends setting
IOBufferSize
so that it is larger than the largest write (multiple concurrent store requests may be combined into a single write).For the best boot recovery time performance of large stores, Oracle recommends setting
IOBufferSize
to at least 2 megabytes.See AllocatedIOBufferBytes to find out the actual allocated off-heap (native) memory amount. It is a multiple of
IOBufferSize
for theDirect-Write
andCache-Flush
policies, or zero.MBean Attribute:
DefaultFileStoreMBean.IoBufferSize
Minimum value:
-1
Maximum value:
67108864
Type Select "Default Store" if you want transactions logged to the server's default store. Select "JDBC" if you want transactions logged to a specific JDBC data source.
MBean Attribute:
TransactionLogJDBCStoreMBean.Enabled
Changes take effect after you redeploy the module or restart the server.
Data Source The JDBC data source used by the transaction log store to log transactions. You cannot configure the transaction log store to use a JDBC data source that is configured to use an XA JDBC driver or configured to support global transactions.
MBean Attribute:
JDBCStoreMBean.DataSource
Changes take effect after you redeploy the module or restart the server.
Prefix Name When using multiple TLOG JDBC stores, use this attribute to create a label ending in "_" that is prepended to the name of the server hosting the JDBC TLOG store and ends in "_" to form a unique JDBC TLOG store name for each configured JDBC TLOG store.
The default prefix name is "TLOG_" . For example, a valid JDBC TLOG store name using the default Prefix Name is
TLOG_MyServer_
where TLOG_ is the Prefix Name and MyServer is the name of the server hosting the JDBC TLOG store.MBean Attribute:
TransactionLogJDBCStoreMBean.PrefixName
Create Table From DDL File Specifies the DDL (Data Definition Language) file to use for creating the JDBC store's backing table.
This field is ignored when the JDBC store's backing table,
WLStore
, already exists.If a DDL file is not specified and the JDBC store detects that a backing table doesn't already exist, the JDBC store automatically creates the table by executing a preconfigured DDL file that is specific to the database vendor. These preconfigured files are located in the
weblogic\store\io\jdbc\ddl
directory of theMIDDLEWARE_HOME\modules\com.bea.core.store.jdbc_x.x.x.x.jar
file.If a DDL file is specified and the JDBC store detects that a backing table doesn't already exist, then the JDBC store searches for the DDL file in the file path first, and then if the file is not found, it searches for it in the CLASSPATH. Once found, the SQL within the DDL file is executed to create the JDBC store's database table. If the DDL file is not found and the backing table doesn't already exist, the JDBC store will fail to boot.
MBean Attribute:
GenericJDBCStoreMBean.CreateTableDDLFile
Changes take effect after you redeploy the module or restart the server.
Maximum Deletes Per Batch The maximum number of table rows that are deleted per database call.
When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests.
Both the maximum batch size for concurrent inserts and for concurrent writes are configurable.
To disable JDBC 3.0 batching, set the maximum batch size to 1.
The maximum batch size has no effect on the maximum number of concurrent client requests.
MBean Attribute:
JDBCStoreMBean.DeletesPerBatchMaximum
Minimum value:
1
Maximum value:
100
Changes take effect after you redeploy the module or restart the server.
Maximum Inserts Per Batch The maximum number of table rows that are inserted per database call.
When possible, a JDBC store uses JDBC 3.0 batching to batch concurrent client requests.
Both the maximum batch size for concurrent inserts and for concurrent writes are configurable.
To disable JDBC 3.0 batching, set the maximum batch size to 1.
The maximum batch size has no effect on the maximum number of concurrent client requests.
MBean Attribute:
JDBCStoreMBean.InsertsPerBatchMaximum
Minimum value:
1
Maximum value:
100
Changes take effect after you redeploy the module or restart the server.
Maximum Deletes Per Statement The maximum number of table rows that are deleted per database call.
Applies only when a JDBC store does not use JDBC 3.0 batching to batch concurrent client requests.
The maximum deletes per statement has no effect on the maximum number of concurrent client requests.
For some databases, the JDBC store may choose a lower value than the one configured.
MBean Attribute:
JDBCStoreMBean.DeletesPerStatementMaximum
Minimum value:
1
Maximum value:
100
Changes take effect after you redeploy the module or restart the server.
Maximum Retry Before Transaction Log Fail (seconds) The maximum amount of time, in seconds, WebLogic Server tries to recover from a JDBC TLog store failure. If store remains unusable after this period, WebLogic Server set the health state to
HEALTH_FAILED
. A value of 0 indicates WebLogic Server does not conduct a retry and and immediately sets the health state asHEALTH_FAILED
.MBean Attribute:
TransactionLogJDBCStoreMBean.MaxRetrySecondsBeforeTLOGFail
Minimum value:
0
Maximum value:
2147483647
Maximum Retry Before Transaction Exception Thrown (seconds) The maximum amount of time, in seconds, WebLogic Server waits before trying to recover from a JDBC TLog store failure while processing a transaction. If store remains unusable after this amount of time, WebLogic Server throws an exception the affected transaction. A value of 0 indicates WebLogic Server does not conduct a retry and an exception will thrown immediately. The practical maximum value is a value less than the current value of
MaxRetrySecondsBeforeTLogFail
.MBean Attribute:
TransactionLogJDBCStoreMBean.MaxRetrySecondsBeforeTXException
Minimum value:
0
Maximum value:
300
Retry Interval (seconds) The amount of time, in seconds, WebLogic Server waits before attempting to verify the health of the TLOG store after a store failure has occurred.
MBean Attribute:
TransactionLogJDBCStoreMBean.RetryIntervalSeconds
Minimum value:
1
Maximum value:
60
Connection Caching Policy The Connection Caching Policy setting controls how many JDBC connections the JDBC Store caches. Oracle strongly recommends that you consult the store administration guide before changing the connection caching policy to None.
MBean Attribute:
TransactionLogJDBCStoreMBean.ConnectionCachingPolicy
Changes take effect after you redeploy the module or restart the server.
Maximum File Size The maximum file size, in bytes, of an individual data file.
The
MaxFileSize
value affects the number of files needed to accommodate a store of a particular size (number of files = store size/MaxFileSize rounded up).A file store automatically reuses space freed by deleted records and automatically expands individual files up to
MaxFileSize
if there is not enough space for a new record. If there is no space left in exiting files for a new record, a store creates an additional file.A small number of larger files is normally preferred over a large number of smaller files as each file allocates Window Buffer and file handles.
If
MaxFileSize
is larger than 2^24 *BlockSize
, thenMaxFileSize
is ignored, and the value becomes 2^24 *BlockSize
. The defaultBlockSize
is 512, and 2^24 * 512 is 8 GB.The minimum size for
MaxFileSize
is 10 MB when multiple data files are used by the store. IfInitialSize
is less thanMaxFileSize
then a single file will be created ofInitialSize
bytes. IfInitialSize
is larger thanMaxFileSize
then (InitialSize
/MaxFileSize
) files will be created ofMaxFileSize
bytes and an additional file if necessary to contain any remainder.See Initial Size.
MBean Attribute:
DefaultFileStoreMBean.MaxFileSize
Minimum value:
1048576
Maximum value:
2139095040
Enable File Locking Determines whether OS file locking is used.
When file locking protection is enabled, a store boot fails if another store instance already has opened the store files. Do not disable this setting unless you have procedures in place to prevent multiple store instances from opening the same file. File locking is not required but helps prevent corruption in the event that two same-named file store instances attempt to operate in the same directories. This setting applies to both primary and cache files.
MBean Attribute:
DefaultFileStoreMBean.FileLockingEnabled
Block Size The smallest addressable block, in bytes, of a file. When a native
wlfileio
driver is available and the block size has not been configured by the user, the store selects the minimum OS specific value for unbuffered (direct) I/O, if it is within the range [512, 8192].A file store's block size does not change once the file store creates its files. Changes to block size only take effect for new file stores or after the current files have been deleted. See "Tuning the Persistent Store" in Tuning Performance of Oracle WebLogic Server.
MBean Attribute:
DefaultFileStoreMBean.BlockSize
Minimum value:
-1
Maximum value:
8192
Initial Size The initial file size, in bytes.
Set
InitialSize
to pre-allocate file space during a file store boot. IfInitialSize
exceedsMaxFileSize
, a store creates multiple files (number of files =InitialSize
/MaxFileSize
rounded up).A file store automatically reuses the space from deleted records and automatically expands a file if there is not enough space for a new write request.
Use
InitialSize
to limit or prevent file expansions during runtime, as file expansion introduces temporary latencies that may be noticeable under rare circumstances.Changes to initial size only take effect for new file stores, or after any current files have been deleted prior to restart.
See Maximum File Size.
MBean Attribute:
DefaultFileStoreMBean.InitialSize
Minimum value:
0
![]() |