このコンテンツは選択した言語では利用できません。
Chapter 1. Introduction to Red Hat JBoss A-MQ Persistence
Abstract
Message persistence allows for the recovery of undelivered messages in the event of a system failure. By default, Red Hat JBoss A-MQ's persistence features are activated. The default set-up is fast and scalable. It is easy to customize the broker configuration to use a JDBC compliant database.
Overview
Loss of messages is not acceptable in mission critical applications. Red Hat JBoss A-MQ reduces the risk of message loss by using a persistent message store by default. Persistent messages are written to the persistent store when they are sent. The messages persist in the store until their delivery is confirmed. This means that, in the case of a system failure, JBoss A-MQ can recover all of the undelivered messages at the time of the failure.
Persistent message stores
The default message store is embeddable and transactional. It is both very fast and extremely reliable. JBoss A-MQ implements several different kinds of message store, including:
- KahaDB message store
- distributed KahaDB message store
- LevelDB message store
- JDBC adapter
- Journaled JDBC adapter (deprecated)
Message cursors
JBoss A-MQ caches message using message cursors. A message cursor represents a batch of messages cached in memory. When necessary, a message cursor can be used to retrieve the batch of persisted messages through the persistence adapter. See Chapter 7, Message Cursors for details.
Activating and deactivating persistence
By default, brokers are configured to use a persistence layer to ensure that persistent messages will survive a broker failure and meet the once-and-only-once requirement of the JMS specification. Having a broker's persistence layer configured comes with a cost in terms of resources used and speed, so for testing purposes or cases where persistence will never be required, it may make sense to disable a broker's persistence layer.
Deactivating a broker's persistence layer means that a broker will treat all messages as non-persistent. If a producer sets a message's JMSDeliveryMode property to
PERSISTENT the broker will not respect the setting. The message will be delivered at-most-once instead of once-and-only-once. This means that persistent messages will not survive broker shutdown.
Persistence in JBoss A-MQ is controlled by a broker's XML configuration file. To change a broker's persistence behavior you modify the configuration's
broker element's persistent attribute.
| Value | Description |
|---|---|
true | The broker will use a persistent message store and respect the value of a message's JMSDeliveryMode setting. |
false | The broker will not use a persistent message store and will treat all messages as non-persistent regardless of the value of a message's JMSDeliveryMode setting. |
Example 1.1, “Turning Off a Broker's Persistence” shows a configuration snippet for turning off a broker's message persistence.
Example 1.1. Turning Off a Broker's Persistence
<broker persistent="false" ... > ... </broker>
Configuring persistence adapter behavior
JBoss A-MQ offers a number of different persistence mechanisms besides the default message store. To use one of the alternative message stores, or to modify the behavior of the default message store, you need to configure the persistence adapter. This is done by adding a
persistenceAdapter element or a persistenceFactory element (depending on the kind of adapter you want to use) to the broker's configuration file.
Customizing the store's locker
For added flexibility in master/slave deployments JBoss A-MQ's message stores have configurable lockers. All of the message stores have a default locker implementation. The default implementation can be replaced by a custom implementation.
Regardless of the implementation, the locker has two configurable properties:
- if the broker should fail if the store is locked
- how long a broker waits before trying to reacquire a lock
