The following sections explain how to tune the persistent store, which provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence.
The following sections provide information on using persistent stores.
Each server instance, including the administration server, has a default persistent store that requires no configuration. The default store is a file-based store that maintains its data in a group of files in a server instance’s
data\store\default directory. A directory for the default store is automatically created if one does not already exist. This default store is available to subsystems that do not require explicit selection of a particular store and function best by using the system’s default storage mechanism. For example, a JMS Server with no persistent store configured will use the default store for its Managed Server and will support persistent messaging. See:
In addition to using the default file store, you can also configure a file store or JDBC store to suit your specific needs. A custom file store, like the default file store, maintains its data in a group of files in a directory. However, you may want to create a custom file store so that the file store's data is persisted to a particular storage device. When configuring a file store directory, the directory must be accessible to the server instance on which the file store is located.
A JDBC store can be configured when a relational database is used for storage. A JDBC store enables you to store persistent messages in a standard JDBC-capable database, which is accessed through a designated JDBC data source. The data is stored in the JDBC store's database table, which has a logical name of
WLStore. It is up to the database administrator to configure the database for high availability and performance. See:
Each JMS server implicitly creates a file based paging store. When the WebLogic Server JVM runs low on memory, this store is used to page non-persistent messages as well as JDBC store persistent messages. Depending on the application, paging stores may generate heavy disk activity.
|Note:||File store persistent messages do not page using a paging store, such messages page directly into and out of their respective file stores.|
JMS paging stores usually require no tuning. You can optionally change the directory location and the thresholds setting at which paging begins. See Paging Out Messages To Free Up Memory.
The location of the JDBC store DDL that is used to initialize empty stores is now configurable. This simplifies the use of custom DDL for database table creation, which is sometimes used for database specific performance tuning. For information, seein Administration Console Online Help and in Configuring WebLogic Server Environments.
The following section provides information on tuning File Stores:
Direct-Writesynchronous write policy.
Direct-Writeis the default write policy. In most applications
Direct-Writeprovides better performance than the
Disabledwrite-policy option can dramatically improve performance, especially at low client loads. However, it is unsafe because writes become asynchronous and data can be lost in the event of Operating System or power failure.