Types of Alarm

Session Alarms are handled on behalf of a session with the Alarm Server. Each session is allowed to set one Session Alarm only. The server tells the session when to set the next alarm. If the session disconnects, the Session Alarm is cancelled.

The Session Alarm is completed when the alarm expires, is cancelled, or a timing error occurs. If a client wants to cancel a Session Alarm it must use RASCliSession::AlarmNotificationCancelAndDequeue(). If the client session is closed before the alarm has expired, the Alarm Server automatically dequeues the alarm. This type of behaviour is indicated by the alarm’s characteristics flag (EAlarmCharacteristicsSessionSpecific) being set.

Session Alarms are deleted when the session to the Alarm Server is closed. An alarm must be orphaned if it is not to be deleted. The session then relinquishes control of it to the Alarm Server.

Non Session Alarms are stored in the server’s orphaned alarm array. It has no session owner, and no session is notified when the alarm is due. When a session closes its connection to the Alarm Server, it may choose to orphan its Session Alarm. This allows the alarm to be serviced after the session closes. An application can regain control of an orphaned alarm by setting an alarm with the same parameters, for example: time or date.

After orphaning an alarm, a session is allocated enough memory for another Session Alarm, which it can also orphan. Sessions can orphan as many alarms as memory allows. The server removes all orphaned alarms when the system time is changed or the Alarm Server is re-started.