This chapter explains how to configure and monitor the WebLogic Server persistent store, which provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence.
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 or when you want a JMS service that accesses a file store to be able to migrate with the store to another server member in a cluster. 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-accessible 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. JDBC stores also support migratable targets for automatic or manual JMS service migration.
For more information about configuring a persistent store, see When to Use a Custom Persistent Store.
WebLogic Server provides configuration options for creating a custom file store or JDBC-accessible store. For example, you may want to:
Place a file store's files on a particular device.
Use a JDBC store rather than a file store for a particular server instance. If you want to persist transaction logs, use a JDBC TLOG store. See Using a JDBC TLog Store.
Allow all physical stores in a cluster to share the same logical name.
Logically separate different services to use different files or tables. (This may simplify administration and maintenance at the expense of reduced performance.)
Migratable JMS-related services cannot use the default persistent store, so you must configure a custom store and target it to the same migratable target as the migratable JMS service. For more information, see "Service Migration" in Administering Clusters for Oracle WebLogic Server.
A user-defined persistent store can be configured in the following ways:
Use the WebLogic Server Administration Console. To configure a custom file store or JDBC store, see "Configure Persistent Stores" in the Oracle WebLogic Server Administration Console Online Help. To configure a JDBC TLOG store, see "Configure the Transaction Log Store" in the Oracle WebLogic Server Administration Console Online Help.
Directly edit the configuration file (
config.xml) of the server instance that is hosting a persistent store.
Use the WebLogic Java Management Extensions (JMX) to create persistent stores. JMX is the Java EE solution for monitoring and managing resources on a network. For more information see, Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.
Use the WebLogic Scripting Tool (WLST) to create persistent stores. WLST is a command-line scripting interface that you use to interact with and configure WebLogic Server instances and domains. For more information, see Understanding the WebLogic Scripting Tool.
Use the WebLogic Configuration Wizard to change the options of the default persistent store. For detailed information on how to use the Configuration Wizard to configure a persistent store, see "Creating a WebLogic Domain" in Creating WebLogic Domains Using the Configuration Wizard.
Modifying certain custom store configuration options, such as a JDBC store's prefix or a file store's directory, do not necessarily require a server restart if you do the following:
Set the targets of any dependent services to null (such as a JMS server that uses the custom store), and then setting the custom store target to null. (Setting a service's target to null implicitly shuts down the service.)
Reverse the process by setting the custom store target back to its original value and then setting the dependent resource targets back to their original values.
In cases where the custom store and JMS servers share a migratable target, you can administratively restart the migratable target.