When all responses are received from surviving connectors, XES performs the following cleanup:

1. Remove entries associated with the failed user, whether the entry represents the user as an owner or a waiter for the resource, from any resource request queues.
2. If the user is not persistent, delete any record data entries associated with the failed user.
3. If the failed user was currently assigned contention management responsibilities, reassign those responsibilities to another connected user.

Resource Request Queues

XES removes the failed user's requests from any resource request queue on which the user is shown to be a resource owner or waiter (that is, has a request pending). Also, XES cancels any requests from the failed user that are waiting to be applied to a resource request queue. If a resource request queue from which the failed user's requests are removed is being managed by the contention exit of a surviving connector, then the updated resource request queue is presented to that user's contention exit. Reason flags in the CEPL will indicate that recovery has occurred. If the contention exit was waiting for a response from the failed connector at the time of the failure (such as a response from the notify exit), then XES will cancel the wait for the response.

Record Data Entries

Whether XES deletes the record data entries associated with the failed user depends on how the user's connection was defined at connect time. If the failed user is transitioning to a failed-persistent state, then the record data entries are kept and are available either for the restarted connector or for peer connectors as part of the recovery protocol. If the failed user was not defined to become failed-persistent, then XES deletes any associated record data entries for the failed user.

Contention Management Responsibilities

The responsibility of managing resource request queues is shared among the instances of XES supporting the connectors to the structure. At any point in time a connector may be managing any number of resource request queues through its contention exit, and the instance of XES supporting the connector may internally be managing additional resource request queues that are not in contention. Whenever a connector disconnects or abnormally terminates, XES reassigns management responsibilities for any resource request queues that were being managed by that connector (or its associated instance of XES) among the remaining connectors and their supporting instances.

After removing the failed user's requests from any resource request queues, the system determines if the failed user's contention exit (or the instance of XES supporting the connector) had been managing any resource request queues at the time of the error. If so, and the queue still contains owners, XES reassigns management responsibilities to the contention exit of another connected user. When the newly selected user's contention exit is first invoked, the CEPL will indicate that recovery has occurred.

Note that because the management of resource request queues is reassigned in these instances without considering the current (or previous) state of the entries on the queue, a contention exit may be presented with a resource request queue containing entries that are compatible. This method of overindicating the state of a resource request queue in failure scenarios ensures that any communications that had been established with local connectors by the contention exit of the failing user will have a chance to be completed by the contention exit of the connector who become the new manager regardless of whether the queue is still in contention after the cleanup has occurred.

You should be aware of the potential for a deadlock environment when XES is waiting to reassign management responsibilities for a resource request queue. XES cannot assign another connected user to manage the resource request queue until all acknowledgments of the failed connection have been received from the surviving connectors through either their event exits or IXLEERSP. Therefore, any resource requests on the queue will remain outstanding until a new contention manager is assigned. A deadlock situation could occur if you delay confirming an XES event while awaiting the completion of an IXLLOCK resource request. The responsibility of detecting and resolving deadlock situations is that of the connected user and not of XES.