Websphere 8: JMS : File Store and Data Store

File stores
File stores use a file system to preserve operating information and to persist the objects that messaging engines need for recovery in the event of a failure.

A file store is a type of message store that directly uses files in a file system through the operating system. The data storage in a file store is split into three levels: the log file, permanent store file, and temporary store file.

The relationship between a messaging engine and its file store 

Log file
This file contains information about currently active transactions and data that is not yet written to a store file. It is a circular log and its file size is static while a messaging engine is running, but can be changed if required. A restart of the messaging engine is required for the changes to take effect. The size of the log file limits the maximum size of a message that can be sent.

Permanent store file
This file contains permanent data that is retained after the restart of the messaging engine, such as persistent messages, queue data, and information about the storage and transmission of persistent messages.
The permanent store file can be configured to have a maximum and minimum size, or to be unlimited in size. The file can grow from the minimum size (or as required in the unlimited case) but will never shrink (even if the maximum size is set lower than its current size). The file sizes can be changed in the administration console, but a restart of the messaging engine is required for the changes to take effect.
Similar to a file system, when data is deleted from the store, the data in the file is not deleted, only the directory information is updated. This means that if a message is consumed, the message data may still be present in the store file, but the directory information that includes this data in the store is updated to reflect the fact that it is deleted.

Temporary store file
This file contains temporary data that is not retained after the restart of the messaging engine, such as non-persistent messages that were spilled to the file store to release memory from the JVM heap. The temporary store file contents are truncated when the messaging engine starts.
The temporary store file can be configured to have a maximum and minimum size, or to be unlimited in size. The file can grow from the minimum size (or as required in the unlimited case) but will never shrink (even if the maximum size is set lower than its current size). The file sizes can be changed in the administration console, but a restart of the messaging engine is required for the changes to take effect.

Similar to a file system, when data is deleted from the store, the data in the file is not deleted, only the directory information is updated. This means that if a message is consumed, the message data may still be present in the store file, but the directory information that includes this data in the store is updated to reflect the fact that it is deleted.


You can configure where the file store files must be placed. By default, the file store uses a subdirectory in the following path: ${USER_INSTALL_ROOT}/filestores/com.ibm.ws.sib/${ME_NAME}. The file store directory contains two other directories; the log directory that contains the log file and the store directory that contains both the PermanentStore and TemporaryStore files.

Data stores
A data store is a message store that uses a relational database. A messaging engine uses a data store to store operating information in the database, as well as to preserve essential objects that the messaging engine needs for recovery in the event of a failure.

A data store consists of the set of tables that a messaging engine uses to store persistent data in a database. See Data store tables for a list of the tables that comprise a data store. All the tables in a data store are held in the same database schema. You can create multiple data stores in the same database, provided that you use a different schema name for each data store.


The one-to-one relationship between a messaging engine and a data store means that every messaging engine must have its own data store. A messaging engine uses an instance of a JDBC data source to interact with the database that contains the data store for that messaging engine. The relationship between a messaging engine and its data store. illustrates these relationships.

The relationship between a messaging engine and its data store

All the tables in the data store must be stored in the same schema. You can create more than one data store in a database, provided that you use a different schema name for each data store. Although every messaging engine uses the same table names, its relationship with the schema gives each messaging engine exclusive use of its own tables.

Data store topologies
You have several options for the relative location of a data store and its messaging engine. The topology also defines the relationship of a data store with other data stores.
The following options affect your choice of data store topology:
• The data store can either run on the same node as its messaging engine or on a remote node.
• The data store can either have a dedicated database or it can share a database with other data stores.

Tip: If you are using the Informix® RDBMS, configure a separate database instance for each messaging engine.
A data store uses a relational database management system (RDBMS), working through JDBC, to store data as rows in a set of tables. This data is important when you are backing up or restoring a data store.
The following table summarizes the purpose of each data store table.

Table name	Purpose
SIBOWNER	Ensures exclusive access to the data store by an active messaging engine.
SIBOWNERO	Used for locking the data store. This table stores no data in its one EMPTY_COLUMN column.
SIBCLASSMAP	Catalogs the different object types in the data store.
SIBLISTING	Catalogs the SIBnnn tables.
SIBXACTS	Maintains the status of active two-phase commit transactions.
SIBKEYS	Assigns unique identifiers to objects in the messaging engine.
SIBnnn, where nnn is a number	Contains persistent objects such as messages and subscription information. These tables hold both persistent and nonpersistent objects, using separate tables for the different types of data.

Note: The SIBOWNERO table was introduced for WebSphere^® Application Server Version 7.0 and must be created when you are migrating to WebSphere Application Server Version 7.0 or later from an earlier version of WebSphere Application Server.

Message store high availability

High availability is achieved by failing over messaging engines between servers. Both file stores and data stores can be deployed in a highly available environment.

In this figure, two servers access a message store that is either a file store accessed through a network file system or a data store that is accessed through a remote database server. This means a messaging engine running on one of the servers can be failed over to the other server, and will retain access to the message store.

Figure 1. Failover of a messaging engine between servers 

Relative advantages of a file store and a data store

When you will use file store over data store?

Better performance

To achieve best performance using a data store, you often have to use a separate remote database server. With file store you can achieve even better performance without having to use a separate remote database server.

Low administration requirements

The file store combines high throughput with little or no administration. This makes it suitable for those who do not want to worry about where the messaging engine is storing its recoverable data. File store improves on the throughput, and scalability of Apache Derby.

Lower deployment costs

Use of data store might require database administration to configure and manage your messaging engines. File store can be used in environments without a database server.

When you will use data store over file store?

Some organizations prefer to use data store because it uses their existing resources more effectively. For example, this might be the case for a company with a strong team of database specialists, or a stable database infrastructure.

If there is a transient connectivity loss to the file system, the application server must be restarted once the connectivity to the file system is restored. Whereas, in the case of the data store, the messaging engine can recover from the database itself. In such situations, the data store will be a preferred high availability option than the file store system.

With data store, some Java EE applications can share JDBC connections and benefit from one-phase commit optimization. File store does not support this optimization.

Security in Message Store : File or Data

Data stored in both data store and file store benefit from security features provided by WebSphere® Application Server when accessed using the WebSphere Application Server APIs, that is when using JMS messaging. Further security features are available depending on the type of message store you use. 

Data store: you access your chosen database by using a userid and password that is administered using the supplied tools for your specified DBMS. Logical and physical separation of your database server can also be used to improve the overall security of your data.

File store: additional security can be provided when using a file store by careful consideration of your file store files. For example, using a secure network-attached drive to store your file store files improves the physical security of your data. Another example is storing your files on an operating system encrypted file system.