Introduction

A session must be created while the application is connected to Tmax, and multiple sessions can be created within a single application. To create a session, the name of the target HMS is required. Once a session is created, various properties can be assigned to the session.

A session has the following basic properties.

A transacted session is created with assigned transacted properties. It is usually used for local transactions. The results of sending and receiving a message are not immediately applied to HMS in a transacted session. The application is determined according to the hms_commit() and hms_rollback() APIs.

For example, if a producer that was created by using a transacted session sends multiple messages and executes hms_rollback(), the messages are ignored before arriving at the destination. Like this, the results of receiving a message are applied depending on the hms_commit() and hms_rollback() APIs. Only AUTO_ACK is available in a transacted session.

An XA session exists to perform 2PC with HMS and another Resource Manager (RM). The start and the end of a transaction are specified using transaction-related APIs (tx_beggin(), tx_commit(), and tx_rollback()) of Tmax. In the state that a transaction has not started, it acts like a general session.

HMS supports not only synchronous sessions where a message is sent after a request is sent but also async sessions where a message can be received without a request. In the cast that a consumer is created with an async session, if listener, the name of a service to be called when a message arrives, is passed, the specified Tmax service is called whenever a messages arrives.

It is used in the publish/subscribe pattern of messaging. A single message is sent to all registered subscribers. If there is no registered subscriber, the message will be discarded.

It is used in the point-to-point messaging. A single message is transmitted to a single receiver. The message sent by a sender will stay in a destination until the receiver fetches the message.

A consumer of a topic is called a subscriber.

A subscriber that has the persistent property is a durable subscriber. A durable subscriber can receive all messages delivered to a destination from when it is created to when it cancels the subscription. When a durable subscriber is disconnected from Tmax, the next messages will be queued in a topic, and when the durable subscriber is reconnected to Tmax, it will continue to receive messages from the queue. HMS identifies a durable subscriber with the name of a subscriber. Therefore, a durable subscriber must have a unique name.

A consumer of a queue is a receiver.

A message selector can be set when a receiver is created. It is used to receive only the messages that meets the specified condition. The syntax of a message selector is the same as that of an SQL condition statement.

For example, if there are properties named "Type" and "Month" in a message, the consumer with the following message selector will only receive the message 'news after April'.

For more information about a message selector, refer to Using a Message Selector.

It is set to the CARRAY type.

It can be set to the following 8 data types that are supported by a field buffer: HMS_CHAR, HMS_SHORT, HMS_INT, HMS_LONG, HMS_FLOAT, HMS_DOUBLE, HMS_STRING, and HMS_CARRAY. A property is set with a name together. The property name must be unique. If a property is set with an existing name, the previous value will be changed.

Creating a message needs a session. And each property needs the space for the property name as well as the data, ensure that enough space has been allocated by considering the size of the message.

The following describes the default scheduled properties defined in HMS. A user cannot define a property with the following property names. Other scheduled properties are not supported currently.

HMSPORT must be set in the SVRGROUP section. To cluster queues, GQINT must also be configured.

In the HMS section, destinations to be clustered must have the same name and GLOBAL=Y must be set.

The messages sent to a global topic are delivered to the global topics of other nodes.

For example, if GLOBAL=Y is set to all nodes (A,B,C) that have the same name of Topic01, the message that have arrived in Topic01 of the node A will be delivered to the Topic01 of B and C.

Only one message can exist and be consumed in a global queue unlike a global topic where a copy is delivered to all configured nodes. Therefore, different clustering methods must be used for the global topic and the global queue.

Each HMS sends and receives information about a global queue based on a specific time (HMSGQINT) cycle. The information includes the number of messages that exist in each queue of the current node, the number of connected clients, etc.

Messages are buffered in each queue to ensure that the message transmission is smooth. The buffer size is calculated by multiplying the number of consumers that connect to the current queue by the constant (GQTHR) specified by a user.

If the number of messages in a queue is less than the calculated buffer size, messages will be retrieved from another node’s queue. The number of messages (GQMAXREQ) that can be obtained at a time can be specified. If this value is large, messages will be filled with small number of requests. However, if it is too large, there may be unnecessary message transmission between nodes.

HMS also has the function to prevent unbalanced queue lengths. It automatically adjusts the lengths of queues if the number of messages exceeds a specific number (GQFULL)