Implementing Callback Methods

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

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 function 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 Status and Status_msg. Rather, you should store dynamic state information in global files.

Note - The cluster administrator can set particular resource properties by using the clresource command or through a graphical administrative command or interface. However, do not call clresource from any callback method because clresource fails during cluster reconfiguration, that is, when the RGM calls the method.

Idempotence of 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 can 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 run its Stop method on it. The same scenarios apply to the Monitor_start and Monitor_stop methods.

For these reasons, you must build idempotence into your Stop and Monitor_stop methods. In other words, repeated calls to Stop or Monitor_stop on the same resource with the same arguments must achieve the same results as a single call.

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

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

How Methods Are Invoked in Zones

If declared in the RTR file, the Global_zone resource type property indicates whether the methods of a resource type execute in the global zone. If the Global_zone property equals TRUE, methods execute in the global zone even if the resource group that contains the resource is configured to run in a non-global zone.

If the resource for which Global_zone equals TRUE is configured in a non-global zone, methods that are invoked in the global zone are invoked with the -Z zonename option. The zonename operand specifies the Oracle Solaris zone name of the non-global zone in which the resource is actually configured. The value of this operand is passed to the method.

If the resource is configured in the global zone, the -Z zonename option is not invoked and the non-global zone name is not passed to the method.

The Global_zone resource type property is described in more detail in Resource Type Properties and in the rt_properties(5) man page.

Skip Navigation Links
Exit Print View
	Oracle Solaris Cluster Data Services Developer's Guide Oracle Solaris Cluster 4.0