The contention exit may inform XES about what actions, if any,
are to be performed for the owners and pending IXLLOCK requests represented
on the resource request queue. Through modification of the appropriate
CEPLENT entry, the contention exit may choose to:
- Grant a pending request, perhaps with changed ownership attributes.
The contention exit allows the resource request, while possibly changing
the ownership attributes requested.
- Deny a pending request.
The contention exit does not allow
the ownership state requested.
- Regrant an owned resource with changed ownership attributes.
The
contention exit changes the ownership data of a resource that is currently
owned.
- Keep a pending request in a pending state.
The contention exit
neither grants nor denies the resource request. The request remains
pending on the resource request queue until it is granted, denied,
or superseded. (When a pending request from a user on the resource
request queue is replaced by a more current request (that is, an ALTER
or RELEASE request) from that user, the previous request is said to
be superseded.)
- Notify a current resource owner that contention exists
The
contention exit may choose to inform one or more users that contention
exists for a resource it owns by executing the notify exit of those
users. The notify exit receives as input a notify exit parameter
list (NEPL) representing the current resource request queue. Based
on its evaluation of the resource request queue, the notify exit may
choose to take actions to alleviate the contention. The IXLSYNCH
service provides the mechanism by which the notify exit of a connected
user may synchronously update or release its interest in a resource.
After the specified notify exits have been executed, the resultant
resource request queue (containing any changes made by the notify
exits) is presented to the contention exit. Through the use of the
notify exit, an application can implement protocols that allow owners
and requestors of a resource to negotiate for ownership.