For a broker to recover in case of failure, it needs to recreate the state of its message delivery operations. To be able to do this, it must save state information to a data store. When the broker restarts, it uses the saved data to recreate destinations and durable subscriptions, to recover persistent messages, to roll back open transactions, and to recreate its routing table for undelivered messages. It can then resume message delivery.
The Message Queue service supports both file-based and JDBC compliant persistence modules (see Figure 3–1). File-based persistence is the default.
Compact the data store to alleviate fragmentation as messages are added and removed.
Synchronize the in-memory state with the physical storage device on every write. This helps eliminate data loss due to system crashes.
Manage the allocation of messages to data store files and manage the resources needed for file management and storage.
File-based persistence is generally faster that JDBC-based persistence; however, some users prefer the redundancy and administrative control provided by a JDBC-compliant store.
JDBC-Based persistence uses a Java Database Connectivity (JDBCTM) interface to connect the broker to a JDBC-compliant data store. To have the broker access a data store through a JDBC driver you must do the following:
Set JDBC-related broker configuration properties. You use these to specify the JDBC driver used, to authenticate the broker as a JDBC user, to create needed tables, and so on.
Use the imqdbmgr utility to create a data store with the proper schema.
Complete procedures for completing these tasks and related configuration properties are detailed in the Chapter 4, Configuring a Broker, in Oracle GlassFish Message Queue 4.4.2 Administration Guide.