Using Callback Methods

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

Accessing Resource and Resource Group Property Information

The callback methods that enable the RGM to control activation of cluster resources might require access to the properties of that resource. The API provides both shell commands and C functions that you can use in callback methods to access the system-defined and extension properties of resources.

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

---

Note -

The cluster administrator can set certain resource properties using the scrgadm(1M) command or through an available graphical administrative interface.

---

The C function for resource property access has a variable argument interface. The API defines string-valued tags that indicate an operation and determine the interpretation of the variable argument list. The "get" access function works in conjunction with "open" and "close" functions that do initialization, finalization, and memory management.

You use three functions together for resource property access:

• scha_resource_open(3HA) initializes access to a resource and returns a handle for scha_resource_get.

• scha_resource_get(3HA) accesses the resource information.

• scha_resource_close(3HA) invalidates the handle and frees memory allocated for scha_resource_get return values.

A single man page describes these three functions. You can access this man page through any of the individual functions, scha_resource_open(3HA), scha_resource_get(3HA), or scha_resource_close(3HA).

A command version of scha_resource_get is provided for use in shell scripts. The command takes as flagged arguments an operation tag, the resource name, and its group name. Additional unflagged arguments might be available for some operation tags. The scha_resource_get(1HA) man page provides details on this access command.

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, which means that 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 should return 0 (success) even if the resource or monitor is already stopped and no work is to done.

---

Note -

The INIT, FINI, BOOT, and UPDATE methods must also be idempotent. A START method need not be idempotent.

---