The following sections explain how to configure and monitor the persistent store, which provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence.
The persistent store provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence. For example, it can store persistent JMS messages or temporarily store messages sent using the Store-and-Forward feature. The persistent store supports persistence to a file-based store or to a JDBC-enabled database.
Table 6-1 defines many of the WebLogic services and subsystems that can create connections to the persistent store. Each subsystem that uses the persistent store specifies a unique connection ID that identifies that subsystem.
For more information about the store connection IDs, see Monitoring Store Connections.
The key features of the persistent store include:
Throughput is the main performance goal of the persistent store. Multiple subsystems can share the same persistent store, as long as they are all targeted to the same server instance or migratable target.
This is a performance advantage because the persistent store is treated as a single resource by the transaction manager for a particular transaction, even if the transaction involves multiple services that use the same store. For example, if JMS and EJB timers share a store, and a JMS message and an EJB timer are created in a single transaction, the transaction will be one-phase and incur a single resource write, rather than two-phase, which incurs four resource writes (two on each resource), plus a transaction entry write (on the transaction log).
Both the file store and the JDBC store can survive a process crash or hardware power failure without losing any committed updates. Uncommitted updates may be retained or lost, but in no case will a transaction be left partially complete after a crash.
The following are some similarities and differences between file stores and JDBC stores:
|Note:||If a database is running on high-end hardware with very fast disks, and WebLogic Server is running on slower hardware or with slower disks, then you may get better performance from the JDBC store.|
In order to properly secure file store data, you must set appropriate directory permissions on all your file store directories. If you require data encryption, you must use appropriate third-party encryption software.
For high availability, a persistent file-based store (default or custom) can be migrated along with its parent server as part of the “whole server-level” migration feature, which provides both automatic and manual migration at the server-level, rather than on the service level. For more information, seesection of Using WebLogic Server Clusters. However, file-based stores must be configured on a shared disk that is available to the migratable target servers in the cluster.
File-based stores and JDBC-accessible stores can also be migrated as part of a “service-level” migration for JMS-related services, such as stores, JMS servers, SAF agents, and the path service, which rely on stores to maintain data. Service-level migration is controlled by a migratable target, which serves as a grouping of JMS-related services, and which is hosted on only one physical server in a cluster. JMS services hosted by a migratable target can be manually migrated, either in response to a server failure or as part of regularly scheduled server maintenance. When the migratable target is migrated, all pinned services hosted by that target are also migrated. For more information on service-level migration, seein Using WebLogic Server Clusters.
Migratable JMS-related services cannot use the default file store, so you must configure a custom file store or JDBC store and target it to the same migratable target as the JMS server, SAF agent, or path service associated with the store.
|Tip:||As a best practice, a path service should use its own custom store and migratable target.|
Migratable file stores must also either be configured on a shared disk that is available to the migratable targets in the cluster or you can use pre/post-migration scripts to migrate a file store’s data to a backup server. See stom Store Availability for JMS Services in Configuring WebLogic Server Environments.
If you have applications that need access to persistent stores that reside on remote machines after the migration of a JMS server or JTA transaction log, then you should implement one of the following highly-available storage solutions:
|Note:||If a file store is disconnected and re-connected again, its host server instance must be rebooted to successfully continue sending/receiving persistent JMS messages. For example, if for some reason the file system containing a file store is unmounted and then remounted, attempts to send persistent JMS messages will generate JMS exceptions until the host server is rebooted.|
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.
The default store can be configured by directly manipulating the DefaultFileStoreMBean parameters. If this MBean is not defined in the domain’s configuration file, then the configuration subsystem ensures that the
DefaultFileStoreMBean always exists with the default values.
Also, the Administration Console enables you to change the default store parameters, such as its default directory location and Synchronous Write Policy, as described inin the Administration Console Online Help.
In addition to using the default file store, you can also configure a custom file store or JDBC store to suit your specific needs, as explained in Using Custom File Stores and JDBC Stores. One exception, however, is the JTA transaction log (TLOG), which always uses the default store. This is because the transaction log must always be available early in the server boot process. For more information about the TLOG, seein Programming WebLogic JTA.
The default store maintains its data in a
data\store\default directory inside the servername subdirectory of a domain’s root directory
For example, if no directory name is specified for the default file store, it defaults to:
where domainname is the root directory of your domain, typically
c:\bea\user_projects\domains\domainname, which is parallel to the directory in which WebLogic Server program files are stored, typically
You can, however, specify another location for the default store by directly manipulating the DefaultFileStoreMBean parameters or by using the Administration Console, as described inin the Administration Console Online Help.
Here’s an example of how a default file store may look in a domain’s configuration file, with the default directory location and Synchronous Write Policy settings overridden:
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-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. 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 store. For example, you may want to:
A customized persistent store can be configured in the following ways:
config.xml) of the server instance that is hosting the default persistent store.
The following sections provide an example of a custom file store and configuration guidelines for choosing a synchronous write policy.
To create a custom file store, you can directly modify the default FileStoreMBean parameters. For instructions on using the Administration Console to create a custom file store, seein the Administration Console Online Help.
The main steps for creating a custom file store are as follows:
Here’s an example of how a custom file store may look in a domain’s configuration file with its files kept in a
Table 6-2 briefly describes the file store configuration parameters that can be modified.
The server instance or migratable target where a file store is targeted. Multiple subsystems can share the same file store, as long as they are all targeted to the same server instance or migratable target.
Optionally used with subsystems, like EJBs, when deploying a module to an entire cluster, but also require a different physical store on each server instance in the cluster. In such a configuration, each physical store would have its own name, but all the persistent stores would share the same logical name.
Optionally defines how hard a file store will try to flush records to the disk. Values are: Direct-Write (default), Cache-Flush, and Disabled.
For more information, see Guidelines for Configuring a Synchronous Write Policy.
For instructions on configuring a custom file store using the Administration Console, seein the Administration Console Online Help.
The default Direct-Write policy is supported on most platforms, and this policy generally performs faster than the Cache-Flush option. For a potential performance boost, stores in direct I/O mode will automatically load a native I/O
wlfileio2 driver. This driver is available on Windows, Solaris, HP, AIX, and Linux platforms.
Changing the default policy to Disabled generally improves file store performance, often quite dramatically, but at the expense of possibly losing sent messages or generating duplicate received messages (even if messages are transactional) in the event of an operating system crash or a hardware failure. This is because transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. Simply shutting down an operating system does not generate these failures, as an OS flushes all outstanding writes during a normal shutdown. Instead, these failures can be emulated by abruptly shutting the power off to a busy server.
|Tip:||To view a running file store’s synchronous write policy and driver, check the
The following sections provide an example of a JDBC store, and information about creating a database table for a JDBC store, either using existing DDL or It also includes instruction on enabling Oracle blob record columns in a DDL file.
To create a JDBC store, you can directly modify the default JDBCStoreMBean parameters. For instructions on using the Administration Console to create a JDBC store, seein the Administration Console Online Help.
For configuration guidelines on using prefixes with JDBC stores and recommended JDBC data source settings, see Guidelines for Configuring a JDBC Store.
The main steps for creating a JDBC store are as follows:
Here’s an example of how a JDBC store may look in the configuration file, using the JDBC data source
MyDataSource, and with a logical name specified:
Table 6-3 describes the JDBC store configuration parameters that can be modified.
The server instance or migratable target where a JDBC store is targeted. Multiple subsystems can share the same JDBC store, as long as they are all targeted to the same server instance or migratable target.
The JDBC data source or multi data source used by this JDBC store to access the store’s database table (
The prefix for the JDBC store’s table is generally entered in the following format:
When using multiple JDBC stores, it is required to set this option to a unique value for each configured JDBC store. When no prefix is specified, the JDBC store table name is simply
Optionally used with WebLogic Server subsystems, like EJBs, when deploying a module to an entire cluster, but also require a different physical store on each server instance in the cluster. In such a configuration, each physical store would have its own name, but all the persistent stores would share the same logical name.
Optionally used with supported DDL (data definition language) files to create the JDBC store’s database table (
For instructions on configuring a JDBC store using the Administration Console, see “” in the Administration Console Online Help.]
When using a JDBC store, the backing database can be any database that is accessible through a JDBC driver. WebLogic Server detects some drivers for supported databases.
For each of these databases, there are corresponding DDL (data definition language) files within the WL_HOME
\server\lib\weblogic.jar file, in the
weblogic/store/io/jdbc/ddl directory, where WL_HOME is the top-level directory of your WebLogic Server installation.
The DDL files are actually text files containing the SQL commands (terminated by semicolons) that create the JDBC store’s database table (
WLStore). Therefore, if you are using a database that is not included in this list, you can copy and edit any one of the existing DDL files to suit your specific database, as described in Creating a JDBC Store Table Using a Custom DDL File.
The JDBC Store Configuration page provides an optional Create Table from DDL File option, through which you can access a pre-configured DDL file that is used to create the JDBC store’s backing table (
WLStore). This option is ignored when the JDBC store’s backing table already exists. It is mainly used to specify a custom DDL file created for an unsupported database, or when upgrading JMS JDBC store tables from a prior release to a current JDBC Store table.
If a DDL file name is not specified in the Create Table from DDL File field, and the JDBC store detects that its backing table does not already exist, the JDBC store automatically creates the table by executing a pre-configured DDL file that is specific to the database vendor (see Supported JDBC Drivers).
If a DDL file name is specified in the Create Table from DDL File field, and the JDBC store detects that its backing table does not already exist, the JDBC store searches for the specified DDL file in the file path first, and then, if not found, searches for the DDL file in the
CLASSPATH. Once found, the SQL within the DDL file is executed to create the JDBC store’s backing table. If the configured file is not found and the table doesn’t already exist, the JDBC store will fail to boot.
To use a different database from those listed in Supported JDBC Drivers, you can copy and edit any one of the existing DDL template files to suit your specific database.
/weblogic/store/io/jdbc/ddldirectory using the following command:
jar xf weblogic.jar /weblogic/store/io/jdbc/ddl
|Note:||If you omit the
|Note:||On Windows systems, for full path names always include the drive letter.|
For Oracle databases, you can use the
oracle_blob.ddl file to create a JDBC store table with a BLOB record column type rather than the default LONG RAW record column type. The
oracle_blob.ddl file is pre-configured and supplied in the WebLogic
CLASSPATH, as described in Supported JDBC Drivers.
To use the Oracle BLOB DDL with a JDBC store:
oracle_blob.ddlfile, as follows:
If you need to preserve data already in a Oracle LONG RAW column, but still want to switch the column to BLOB, do not use this method. Instead, consult the Oracle documentation for the SQL ALTER TABLE command.
utils.Schema utility allows you to regenerate a new JDBC store database table (
WLStore) by deleting the existing version. Running this utility is usually not necessary, since WebLogic Server automatically creates this table for you. However, if your existing JDBC store database table somehow becomes corrupted, you can delete it using the
utils.Schema utility is a Java program that takes command-line arguments to specify the following:
utils.Schema command, as follows:
$ java utils.Schema
Table 6-5 lists the
utils.Schema command-line arguments.
The full pathname of the DDL text file containing the SQL commands that you want to execute. For more information, see Supported JDBC Drivers.
For example, the following command deletes a JDBC table named
MYWLStore in an Oracle server named
DEMO, with the user name
user1 and password
$ echo "drop MYWLStore;" > drop.ddl
$ java utils.Schema
weblogic.jdbc.oci.Driver -u user1 -p foobar -verbose \
The following sections provide guidelines for using JDBC store prefixes, recommended WebLogic JDBC data source settings for JDBC stores, and handling JMS transactions with JDBC stores.
The JDBC store database contains a database table, named
WLStore, that is generated automatically and is used internally by WebLogic Server. The JDBC store provides an optional Prefix Name parameter, which can be used to provide more precise access to the database table.
It is always a best practice to configure a prefix for the JDBC
WLStore table name, especially when:
To avoid potential data loss, follow these rules:
For most databases, the Prefix Name option for the JDBC store’s backing database table should be set in the following format for each configured JDBC store, which will result in a valid table name when prepended to the JDBC store table name:
Note that each period in the
[[[catalog.]schema.]prefix] format is significant. Generally,
catalog identifies the set of system tables being referenced by the DBMS, and schema generally corresponds to ID of the table owner (username). When no prefix is specified, the JDBC store table name is simply
WLStore and the database implicitly determines the schema according the current user of the JDBC connection.
For example, in a production database, the database administrator could maintain a unique table for the Sales department, as follows:
The resulting table will be created in the Production catalog, under the JMSAdmin schema, and will be named
For some DBMS vendors, such as Oracle, there is no catalog to set or choose, so the format simplifies to
[[schema.]prefix]. For more information, refer to your DBMS documentation for instructions on fully-qualified table names, but note that the syntax specified by the DBMS may differ from the format required for this option.
|Caution:||If the Prefix Name setting is changed, but the
The following settings are recommended when you use a JDBC data source or multi data source for JDBC stores.
WebLogic Server provides robust JDBC data sources that can automatically reconnect to failed databases after they come back online, without requiring you to restart WebLogic Server. To take advantage of this capability, and make your use of JDBC stores more robust, configure the following options on the JDBC data source associated with the JDBC store:
For more information about JDBC default Test Table Names, seein the Configuring and Managing WebLogic JDBC. For more information about setting the number of database reconnection attempts, see the section in Configuring and Managing WebLogic JDBC.
For data sources used as a JDBC store that use the WebLogic Type 4 JDBC driver for DB2, the
BatchPerformanceWorkaround property must be set to “true” due to internal JMS batching requirements.
For more information, see thesection in the WebLogic Type 4 JDBC Drivers documentation.
You cannot configure a JDBC store to use a JDBC data source that is configured to support global transactions. The JDBC store must use a JDBC data source that uses a non-XA JDBC driver. In addition, you cannot enable Logging Last Resource or Emulate Two-Phase Commit in the data source. This limitation does not remove the XA capabilities of layered subsystems that use JDBC stores. For example, WebLogic JMS is fully XA-capable regardless of whether it uses a file store or any JDBC store.
Because the JDBC store implements the XAResource interface, it acts as it’s own resource manager and handles the transactions above the JDBC driver level. That is, the store itself implements the
XAResource and handles the transactions without depending on the database (even when the messages are stored in the database).
This means that whenever you are using a JDBC store and a database (even if it is the same database where the JMS messages are stored), then it is two-phase commit transaction.
For more information about using JMS transactions with a JDBC store, seein Programming WebLogic JMS.
From a performance perspective, you may also boost your performance as follows:
With the LLR optimization, the transaction will follow the two-phase commit protocol, but the database operations will be handled in a single local transaction, which may improve overall transaction performance. For more information on using the LLR optimization, see in Configuring and Managing WebLogic JDBC.
You can monitor statistics for each existing persistent store and for each open store connection.
Each persistent store is represented at runtime by an instance of the PersistentStoreRuntimeMBean, which provides the following options.
For each open persistent store connection, the persistent store also registers a PersistentStoreConnectionRuntimemMBean, which provides the following options.
Table 6-8 defines most of the runtime prefix names of the WebLogic services and subsystems that can create a connection to the persistent store.
where internal is the name of the JMS server connection
The WebLogic Store administration utility enables administrators to troubleshoot a WebLogic persistent store. The store utility operates only on a store that is not currently opened by a running server instance. This utility can be run from a Java command-line or from WLST (WebLogic Scripting Tool), as described in Store Administration Using a Java Command-line and Store Administration Using WLST.
The most common uses-cases for store administration are for compacting a file store to reduce its size and for dumping the contents of a file store of JDBC store to an XML file for troubleshooting purposes. Examples of these use cases are provided later in this section.
Table 6-9 defines the available store administration commands for Java and WLST.
Compacts and defragments the space occupied by a file store. This command only works offline and does not work for JDBC stores.
A persistent store can be backed by the file system (file store) or by a JDBC-capable database (JDBC store). Except for the
openjdbcstore() options, there is no difference in the options to operate on these two different types of stores.
Most commands and methods work in terms of store names, while others also work in terms of connection names. Store connections are logical groups of records within persistent stores. For example, the JMS and JTA subsystems persist their respective records in different connections in the same store.
To open the persistent store administration utility from a Java command-line, type the following:
> java weblogic.store.Admin> storeadmin->
help for detailed descriptions on available store administration commands, as well as examples of typical command usage. For example, the following comprehensive help is provided for the
list command, which lists store names, open stores, or connections in a store.
lists store names, open stores, or connections in a store
list [-store storename|-dir dir]
list #lists all opened stores by storename
list -store store1 #lists all connections in store1
list -dir dir1 #lists all storenames found in dir1
Here’s an example of using a series of store administration commands to ultimately export the contents of a file store named
myfilestore into a human-readable XML file format in a temporary directory. This does not include store connection names or the actual record contents, which require the optional
> storeadmin-> list -dir .
> storeadmin-> openfile -store myfilestore -dir .
> storeadmin-> dump -store myfilestore -out d:\tmp\filestore1-out
> storeadmin-> close -store myfilestore
list command shows all the store names in the current directory. The
openjdbc commands must be used to open and/or create a file or JDBC store first before calling certain administration functions, like
list (only when listing open stores). After administering an open store, you must close it using the
Here’s an example of using the
compact command to compact the space occupied by a file store in the
> storeadmin->compact -dir c:\mystores -tempdir c:\tmp
Since the compact command can only be used on an unopened file store, none of the stores that have files in the source
-dir directory should be open. Also, the temporary
-tempdir directory should have at least enough extra space as the source directory and should also not be under the source directory. When compact successfully completes, the newly compacted store files will be in the
mystores directory. In addition, a new, uniquely-named directory will be created under
tmp containing the original uncompacted store files.
The WLST interface has a couple of additional methods (compared to the Java command-line) such as
getstoreconns, that return relevant Java objects and can be used for scripting in WLST.
To access the persistent store administration utility from WLST, type the following command:
helpstore() for detailed descriptions on available store administration commands, as well as examples of typical command usage. For example, the following help is provided for the
list command, which lists store names, open stores, or connections in a store.
> wls:/offline> helpstore(liststore)
lists storenames, opened stores, or connections (for interactive access)
Parameters store and dir cannot both be specified concurrently.
@param store [optional] a previously opened JDBC or File store's name.
If store is specified, all connections in the store are listed.
@param dir [optional] directory for which to list available store names
If dir is specified, all store names in the directory are listed.
If neither store nor dir are specified, all open store names are listed.
@return 1 on success, 0 on failure
Note that the parameters with an equal sign “
=” are optional. For example, the
compactstore method can be invoked as either
compactstore(dir='storename', tempdir='/tmp') or
tempdir takes the default value. Default values for optional parameters are listed in the command-specific help.
Here’s an example of using the
dumpstore method (
store, outfile, conn='null', deep='false') to export the contents of a JDBC store named myJDBCStore in a human-readable XML file format out to a file named
mystoredump-out.xml. This does not include store connection names or the actual record contents, which require the optional
'jmstest', 'jmstest', '', 'jdbcstoreprefix')
openfilestore methods must be used to open and/or create a store first before calling certain administration functions, like
liststore (only when listing open stores). After administering an open store, you must close it using the
Here’s an example of a WLST script that uses the
(dir,tempdir=’null’) to compact the space occupied by a file store files in the
> wls:/offline> compactstore('c:\mystores','c:\tmpmystore.dir')
compactstore() method can only be used on unopened file stores, none of the stores that have files in the source
‘dir’ directory should be open. Also, the temporary
‘tempdir’ directory should have at least enough extra space as the source directory and should also not be under the source directory. When compact successfully completes, the newly compacted store files will be in the
mystores directory. In addition, a new, uniquely-named directory will be created under
tmpmystore containing the original uncompacted store files.
The following limitations apply to the persistent store: