The server instances or migratable targets defined in the
current domain that are candidates for hosting the file store.

In a clustered environment, a recommended best practice is to
target a custom file store to the same migratable target as the
migratable JMS service, so that a member server will not be a
single point of failure. A file store can also be configured to
automatically migrate from an unhealthy server instance to a
healthy server instance with the help of the server health
monitoring services.

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 Performance and Tuning for
Oracle WebLogic Server.

The location of the cache directory for
Direct-Write-With-Cache, ignored for other
policies.

When Direct-Write-With-Cache is specified as the
SynchronousWritePolicy, 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 is
CacheDirectory/WLStoreCache/StoreNameFileNum.DAT.cache.
When specified, Oracle recommends using absolute paths, but if the
directory location is a relative path, then
CacheDirectory is created relative to the WebLogic
Server instance's home directory. If "" or Null is
specified, the Cache Directory is located in the
current operating system temp directory as determined
by the java.io.tmpdir Java System property (JDK's
default: /tmp on UNIX, %TEMP% on Windows)
and is
TempDirectory/WLStoreCache/DomainName/unique-id/
StoreNameFileNum.DAT.cache. The value of
java.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, a
Warning 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.

A priority that the server uses to determine when it deploys an
item. The priority is relative to other deployable items of the
same type.

For example, the server prioritizes and deploys all EJBs before
it prioritizes and deploys startup classes.

Items with the lowest Deployment Order value are deployed first.
There is no guarantee on the order of deployments with equal
Deployment Order values. There is no guarantee of ordering across
clusters.

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 of
Direct-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.

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.

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
native wlfileio 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 and Cache-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
(including Disabled).

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 the Direct-Write and
Cache-Flush policies, or zero.

The name used by subsystems to refer to different stores on
different servers using the same name.

For example, an EJB that uses the timer service may refer to its
store using the logical name, and this name may be valid on
multiple servers in the same cluster, even if each server has a
store with a different physical name.

Multiple stores in the same domain or the same cluster may share
the same logical name. However, a given logical name may not be
assigned to more than one store on the same server.

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, then MaxFileSize is ignored,
and the value becomes 2^24 * BlockSize. The default
BlockSize is 512, and 2^24 * 512 is 8 GB.

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 and Disabled but
only when the native wlfileio 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 honor
MinWindowBufferSize.

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.

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 and Disabled, but
only when a native wlfileio library is loaded. See Maximum Window Buffer Size.

Optional information that you can include to describe this
configuration.

WebLogic Server saves this note in the domain's configuration
file (config.xml) as XML PCDATA. All left angle
brackets (<) are converted to the XML entity
&lt;. Carriage returns/line feeds are
preserved.

Note:

If you create or edit a note from the Administration Console,
the Administration Console does not preserve carriage returns/line
feeds.

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 is
Direct-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-perform
Cache-Flush and tend to be slower than
Direct-Write-With-Cache. This mode does not require a
native store wlfileio 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 the Cache
Directory. The Cache Directory provides
information about disk space, locking, security, and performance
implications. This mode requires a native store
wlfileiocode driver. If the native driver cannot be
loaded, then the write mode automatically switches to
Direct-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 to Disabled.

Notes:

When available, file stores load WebLogic wlfileio
native drivers, which can improve performance. These drivers are
included with Windows, Solaris, Linux, HP-UX, 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 a
Direct-Write (default) or
Direct-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 Windows Write Cache
Enabled setting, or by using a power-protected storage
device. See http://support.microsoft.com/kb/281672
and http://support.microsoft.com/kb/332023.

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 native
wlfileio 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 Performance and Tuning for Oracle WebLogic
Server.

Overrides the name of the XAResource that this store registers
with JTA.

You should not normally set this attribute. Its purpose is to
allow the name of the XAResource to be overridden when a store has
been upgraded from an older release and the store contained
prepared transactions. The generated name should be used in all
other cases.

If the specified attribute has not been set explicitly, and if
the attribute has a default value, this operation forces the MBean
to persist the default value.

Unless you use this operation, the default value is not saved
and is subject to change if you update to a newer release of
WebLogic Server. Invoking this operation isolates this MBean from
the effects of such changes.

Note:

To insure that you are freezing the default value, invoke the
restoreDefaultValue operation before you invoke
this.

This operation has no effect if you invoke it on an attribute
that does not provide a default value or on an attribute for which
some other value has been set.