Database Reference
In-Depth Information
JMS file store name
Sample location
Shared
Yes
SOAJMSFileStore_auto_2 /soa_domain/soacluster/jms/
SOAJMSFileStore_auto_2
By virtue of the file stores being shared, they are accessible to all nodes in the
cluster. The recommendation here is to implement one of the following backup
strategies for JMS file-based persistent stores:
•
Move the JMS modules to a JDBC-enabled persistent store. Database
backups will ensure the consistency of the data in the event of a database
restore, but restoring to older backups of the database may result in data in-
consistency.
•
Ensure that the file-based persistent stores reside in fully redundant shared
storage accessible to all nodes of the cluster, and guarantee its availability.
Backing up these stores is possible, but there are implications regarding
message loss and message duplication should you choose to restore them.
The only scenario perhaps where file stores can be backed up is in non-pro-
duction environments where data consistency is not critical such as develop-
ment or test environments. In this case, it is still recommended to take an off-
line backup (that is, where all mid-tier nodes are shut down while the backup
is being performed). Restoring from this backup essentially performs a point-in-
time recovery where the file stores may contain older JMS messages that have
already been consumed and processed. It may also result in lost messages.
For example, messages may have been enqueued but not consumed before the
backup. The only advantage to backing up your JMS file store is that it allows
the administrator to always take a single, working, and consistent backup of the
environment, but with the risk of data duplication and/or inconsistency as a res-
ult of restoring older file stores.
