Directing Work Requests to a Specific Server Region

Existing workload manager interfaces allow a control region to queue work requests to a pool of server regions for a service class. The underlying assumption is that each work request represents one or multiple contiguous transactions. This transaction is represented by an enclave which is created when the work request is inserted and which is removed when the application completed its processing for the work request. It is assumed that no information is left in any temporary structure in the system for following work requests.

But there are cases where information must be preserved across multiple "independent" work requests. The information left behind lives only in the virtual storage of the address space. Following work requests requiring this information must now be directed to the server region which has this information.

The solution is that the server region is able to obtain a region token at select time (IWM4SSL) or connect (IWM4CON) and passes this region token to the queue manager. The queue manager is now able to route subsequent requests directly to this server region by specifying the region token on IWM4QIN. A new interface (IWM4TAF) allows the server or control region to mark the server region as being needed by follow-on work requests. WLM will ensure that server region stays alive until all temporal affinities have been removed.

Notes:

The requests which are directly routed to server regions are outside of the control scope of WLM. Therefore WLM is not able to manage the number of server regions properly if the majority of requests is directly routed to the regions and not queued for being picked up by the WLM managed server pool. It is assumed that requests which are outside of the scope of WLM represent only a minor portion of all work requests processed by the application.
The application should carefully use the new interface IWM4TAF. WLM will not terminate a server region if it is marked of having a temporal affinity. This can significantly delay the behaviour of WLM operator commands such as refresh and quiesce for these application environments. It is assumed that temporal affinities live only a short period (a few minutes) in the system and that they do not represent the majority of the work requests of the application (see also Note 1.)