Adapter Development Kit 6.5 | webMethods Adapter Development Kit Documentation | webMethods Adapter Development Kit Installation and User’s Documentation | Polling Notifications | Cluster Support for Polling Notifications | Callback Coordination
 
Callback Coordination
When a callback is coordinated across the cluster, that callback is only executed on one instance of the polling notification in the cluster. For example, if the enableCallBack is coordinated, the first polling notification in the cluster to be enabled will execute the enableCallBack. When subsequent instances of that notification are enabled, the enableCallBack call is suppressed. If the callbacks were not coordinated, each instance would execute the enableCallBack when the node instance was enabled.
The purpose of callback coordination is to prevent redundant updates to the backend associated with starting or stopping a notification. For example, when the disableCallBack is called on a polling notification for the webMethods JDBC Adapter, a database trigger that gathers information for the notification is removed. Without coordination, all instances of that notification would be effectively disabled as soon as the first instance was disabled. With coordination, the disableCallBack is not executed until the last instance of that notification in the cluster is disabled.
From a design standpoint, it is important to segregate management of resources on the backend in separate callbacks from management of resources that are local to the notification instance. Callback coordination is configured so that related pairs of callbacks are either coordinated, or not. The following pairs of callbacks may be coordinated:
*Enable/Disable. This occurs when the persistent node state is changed from or to "disabled". When coordinated, the first instance to go from "disabled" to "enabled" will execute the enableCallBack and the last instance to go from either "suspended" or "enabled" to "disabled" executes the disableCallBack.
*Startup/Shutdown. This occurs when the node becomes active or inactive for any reason, including when the node is enabled, disabled, suspended, or resumed (if the node is enabled, it also includes server and package startup or shutdown). When coordinated, the first instance to become active will execute the startupCallBack and the last instance to become inactive executes the shutdownCallBack.
*Suspend/Resume. This occurs when the node is suspended or resumed. When coordinated, the first instance to go from "enabled" to "suspended" will execute the suspendCallBack and the last instance to go from either "suspended" to "enabled" executes the resumeCallBack.
For information on how to configure callback coordination, see Configuration Settings.