Jolt 1.2 Developer's Guide

Notification Event Handler
For both unsolicited notifications and a brokered event notification, the Jolt client application requires an event handler routine that is invoked upon
receipt of a notification. The Jolt 1.2 release only supports a single handler per session. In current NonStop
TM
TUXEDO versions, it is not possible
to determine which event generated a notification. Thus it is not possible to invoke an event-specific handler based on a particular event.
The client application must provide a single handler (by overriding the onReply() method) per session that will be invoked for all notifications
received by that client for that session. The single handler call-back function is used for both unsolicited and event notification types. It is up to the
(user supplied) handler routine to determine what event caused the handler invocation and take appropriate action. If the user does not override the
session handler, then notification messages are silently discarded by the default handler.
The Jolt client provides the call back function by subclassing the JoltSession class and overriding the onReply() method with a user-defined
onReply() method.
In NonStop
TM
TUXEDO/ATMI clients, processing in the handler call-back function is limited to a subset of ATMI calls. This restriction does not
apply to Jolt clients. Separate threads are used to monitor notifications and run the event handler method. A Jolt client will be able to perform all
Jolt-supported functionality from within the handler. All the rules that apply to a normal Jolt client program apply to the handler, such as a single
transaction per session at any time.
Each invocation of the handler method takes place in a separate thread. The application developer should ensure that the onReply() method is either
synchronized or written thread-safe, since separate threads could be executing the method simultaneously.
Subscribing to Event Notifications Enables Unsolicited Notifications
Jolt uses an implicit model for enabling the handler routing. When a client subscribes to an event, Jolt will internally enables the handler for that
client, thus enabling unsolicited notifications as well. A Jolt client cannot subscribe to event notifications without also receiving unsolicited
notifications. In addition, a single onReply() method is invoked for both types of notifications.
Connection Modes
Jolt supports notification receipt for clients working in either connection-retained or connection-less modes of operation. Connection-retained
clients receive all notifications. Jolt clients working in connection-less mode will receive notifications while they have an active network connection
to the Jolt Session Handler (JSH). When the network connection is closed, the JSH logs and drops notifications destined for the client. Jolt clients
operating in a connection-less mode will not receive unsolicited messages or notifications while they do not have an active network connection. All
messages received during this time are logged and discarded by the JSH.
Acknowledged Notifications
Connection mode notification handling includes acknowledged notifications for Jolt 1.2 clients in a NonStop
TM
TUXEDO environment. If a JSH
receives an acknowledged notification for a client and the client does not have an active network connection, the JSH logs an error and return a
failure acknowledgment to the notification.