This section applies only to queue managers using the Java programming
interface.
It is sometimes required that applications have a queue manager which
exists in memory only. WebSphere MQ Everyplace 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.
A WebSphere MQ Everyplace 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 WebSphere MQ Everyplace queue managers have the following
characteristics:
- Functionally they can do everything other WebSphere MQ Everyplace 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 WebSphere MQ
Everyplace 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 usually 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.
© IBM Corporation 2002. All Rights Reserved