This topic applies only to the Java™ code base.
It is sometimes required that applications have a queue manager which exists
in memory only. MQe Version 2.0 provides the ability to configure and use
a queue manager using memory resources only, without the need to persist any
information at all to disk.
An MQe queue manager normally uses two mechanisms to store data:
- Configuration information is stored via a registry to an adapter.
- Messages are stored via a message store, which in turn uses an adapter
to store data.
The default is the MQeDiskFieldsAdapter, which persists information to
disk.
Using the MQeMemoryFieldsAdapter instead of the MQeDiskFieldsAdapter for
both of these tasks allows the queue manager to be defined, used to transmit
and store messages, and deleted all without accessing a disk.
In-memory MQe queue managers have the following characteristics:
- Functionally they can do everything other MQe queue managers can do.
- Nothing is stored to disk.
- Messages and configuration stored to registries or queues are nonpersistent.
They are lost if all instances of the MQeMemoryFieldsAdapter are garbage collected,
or in the event of the JVM being shut down.
- The same steps are required to configure the in-memory queue manager,
except they are required every time the JVM is started.
- Transient queue managers which are created, used, and destroyed can be
easier to implement, with no clean-up problems if the JVM terminates abnormally.
Solutions that find this particular configuration of an MQe queue manager
useful have the following properties:
- Disk space is not available or nonexistent, for example in Java applets.
- Message traffic is synchronous only to remote queue managers.
- The application requires no local message store which cannot be recovered
from elsewhere if the JVM is terminated.
- The highest performance is required. Memory operations are much faster
than disk operations, so configuring a queue manager using purely memory resources
normally increases performance of queue manager configurations which, otherwise
store information to disk. Using too much memory can result in thrashing,
and synchronous remote queues ususally run at the same speed on a memory-hosted
or disk-hosted queue manager.
- Creation and sending of messages for which no replies are required, though
in-memory queue managers can obtain replies, you would normally leave replies
on persistent queue managers and browse or get them using a synchronous remote
queue.
An example of the configuration technique can be seen in the examples.queuemanager.MQeMemoryQM class.
Note that the MQeMemoryFieldsAdapter is instantiated explicitly at the start,
and a reference is held until the point where the queue manager, and messages
it contains are no longer required.
Note also that it is still important that in-memory queue managers have
names which are unique within the messaging network.