Implementing Callback Methods

This section provides some information that pertains to implementing the callback methods in general.

Accessing Resource and Resource Group Property Information

Generally, callback methods require access to the properties of the resource. The RMAPI provides both shell commands and C functions that you can use in callback methods to access the system-defined and extension properties of resources. See the scha_resource_get(1HA) and scha_resource_get(3HA) man pages.

The DSDL provides a set of C functions (one for each property) to access system-defined properties, and a function to access extension properties. See the scds_property_functions(3HA) and scds_get_ext_property(3HA) man pages.

You cannot use the property mechanism to store dynamic state information for a data service because no API functions are available for setting resource properties (other than for setting Status and Status_msg). Rather, you should store dynamic state information in global files.

The cluster administrator can set certain resource properties using the scrgadm command or through an available graphical administrative command or through an available graphical administrative interface. However, do not call scrgadm from any callback method because scrgadm fails during cluster reconfiguration, that is, when the RGM calls the method.

Idempotency for Methods

In general, the RGM does not call a method more than once in succession on the same resource with the same arguments. However, if a Start method fails, the RGM could call a Stop method on a resource even though the resource was never started. Likewise, a resource daemon could die of its own accord and the RGM might still invoke its Stop method on it. The same scenarios apply to the Monitor_start and Monitor_stop methods.

For these reasons, you must build idempotency into your Stop and Monitor_stop methods. Repeated calls of Stop or Monitor_stop on the same resource with the same parameters achieve the same results as a single call.

One implication of idempotency is that Stop and Monitor_stop must return 0 (success) even if the resource or monitor is already stopped and no work is to done.

The Init, Fini, Boot, and Update methods must also be idempotent. A Start method need not be idempotent.