Failover Cluster Development Guidelines

The following information applies to all cluster programming tasks.

Follow the standard order of preference when selecting an API to use.

The various subsets of the Failover Cluster API sometimes present you with multiple ways to do the same thing. The standard order of preference describes how to choose the best API for your type of application.

Do not use any registry functions that are not part of the Failover Cluster API on any cluster database keys.

They will corrupt the data and make the cluster unusable. Only the Failover Cluster API can work with the cluster database safely. This applies only to keys in the cluster hive (HKEY_LOCAL_MACHINE\CLUSTER), not to checkpointed registry keys external to the cluster database.

Refresh often and use caution when working with property values.

Keep in mind the possibility that a new value has been written to a property immediately after you read or write the old value (see Multiple and Simultaneous Property Updates). Refresh local property data before relying on a specific value.

Do not mix LPC and RPC handles in the same API call.

If an API takes more than one cluster object handle as a parameter, be sure that all handles are RPC or that all handles are LPC. Mixing handle types results in an RPC exception and may have other unpredictable results. For more information, see LPC and RPC Handles.

Close handles after deleting objects

The DeleteClusterResource and DeleteClusterGroup functions do not close the handles to the deleted objects. To avoid memory leaks, call CloseClusterResource and CloseClusterGroup on the handles to the deleted objects.

Note which API elements express string sizes as counts of characters and which express string sizes as counts of bytes.

For more information see Data Size Conventions.