Overview

Universal Message Service (OMS) provides reliable message delivery between OMS clients, even in the case of system failures. Message reliability is accomplished, in part, with a persistent OMS message database for saving messages to persistent storage. The OMS message database ensures that each message written to the database is flushed to disk before considering the message successfully saved.

Message Database Structure

The database is composed of one or more message data files and a message index. The message data files are sequential files that contain the OMS messages. The message data files keep a journal of all message operations, such as adding a message, delivering a message, and deleting a message. The message index is high-performance index into the messages contained in the message data files. The index is always created anew when the OMS Server starts.

Message Data File

Message data files are sequential files in which all message I/O operations are maintained. Message I/O operations are represented as records, which are always appended to the active message data file. Consequentially, the message data file is logically an ordered journal of message I/O operations.

The size of a message data file will grow to a maximum size that is configured with the MAX_DATA_FILE_SIZE OMS configuration option, which defaults to 25 megabytes. When the active message data file maximum size has been reached, the message data file is closed, reopened for read-only access, and a new active message data file is created.

Message data files are deleted by an OMS Server clean-up process that runs periodically or when the OMS Server starts as part of the database validation. The OMS Server message data file clean-up process will analyze all the message data files to determine if they contain any undelivered messages. If an undelivered message is found in a message data file, that message data file - as well as any subsequent message data files - will not be deleted. When all messages have been delivered, the message data file is deleted. The time interval in which message data file clean-up is performed is configured with the MSG_CLEANUP_INTERVAL OMS configuration option, which defaults to 30 minutes.

Message Index

The message index file is a keyed index into the message data files used, which provides high-performance access to the OMS messages. The message index is created each time the OMS Server starts.

Message Database Environment

The OMS message database location is specified by the SPOOL_DIRECTORY OMS configuration option. The default directory is platform-dependent.

The message database can reside on a network file system or a SAN. The only requirement is that when the OMS Server executes on a UNIX platform, the file system must support POSIX advisory file locks when the OMS Server is part of a High Availability cluster.

The message database directory contains the following files:

Message Database Performance

OMS Server throughput depends largely on the performance of the I/O subsystem on which the message database resides. Each record written to the message data file is flushed to disk, so buffering has no effect on performance. For that reason, the OMS Server message database should reside on a sufficiently fast I/O subsystem. Precise hardware configurations are beyond the scope of this document. The OMS Administration Utility does include an I/O test command that can be used to test the performance of an I/O subsystem.

Message Database Portability

Message data files and the message index are not portable between different platforms. The data stored in the message files contain data types that are formatted according to the platform on which they were created. For example, if the OMS Server is executing on a UNIX 32-bit, big-endian platform, the message data files cannot be moved to a UNIX 64-bit platform, nor to a UNIX little-endian platform. Generally, the message database files must not be moved between different operating systems or hardware architectures.

Message Database Reliability

The OMS message database can sustain system interruptions without loss of data. When the OMS Server starts, it performs message database validation on all message data files. If a corrupted message data file is found, it is truncated at the last good record. Prior to recovering a corrupted message data file, an archive version of the file is created with an extension .archive.

A message data file can become corrupted for a number of reasons, but the most likely reason is an uncontrolled shutdown of the OMS Server process or the host on which the OMS Server is executing. In the case of an uncontrolled shutdown during a write operation, since all I/O operations on the message data files are append operations, only the last record being written at the time of the interruption will be corrupted. Message database validation will detect the corrupted record and truncate the file to removed the corrupted record. Since the corrupted record was never successfully written, the OMS message was never considered to have been successfully persisted. The OMS client that produced the message will resend the message when its OMS server connection has been reestablished.

The message database cannot be recovered from a corrupted file system or disk sectors. For this reason, the message database should reside on a reliable, fault-tolerant file system and hardware configuration, such as a RAID configuration, in order to maintain database reliability in the event of a hardware or operating system fault. The message database cannot be backed up for reasons described below. A reliable, fault tolerant file system and hardware configuration is highly recommended.

Message Database Backup

The message database should not be backed up. The reason is that a restored backup can potentially contain undelivered OMS messages that were actually delivered since the time the backup was made. The OMS Server would redeliver the message, potentially resulting in many duplicate messages being delivered to OMS clients with unpredictable consequences.