2.4.3 Server affinity

The previous discussion implies that any load-distribution facility, when it chooses a server to direct a request, is not entirely free to select any available server: - In the case of stateful session beans or entity beans within the context of a transaction, there is only one valid server. WebSphere WLM always directs a client's access of a stateful session bean to the single server instance that contains the bean (there is no possibility of choosing the wrong server here). If the request is directed to the wrong server (for example because of a configuration error), it either fails or that server itself is forced to forward the request to the correct server at great performance cost.

- In the case of clustered HTTP sessions or entity beans between transactions, the underlying shared database ensures that any server can correctly process each request. However, accesses to this underlying database might be expensive, and it might be possible to improve performance by caching the database data at the server level. In such a case, if multiple consecutive requests are directed to the same server, they might find the required data still in the cache and, thereby, reduce the overhead of access to the underlying database.

The characteristics of each load-distribution facility, which take these constraints into account, are generally referred to as server affinity. In effect, the load distribution facility recognizes that multiple servers might be acceptable targets for a given request, but it also recognizes that each request might have a particular affinity for being directed to a particular server where it can be handled better or faster.

We encounter this notion of server affinity throughout the discussion of the various load-distribution facilities. In particular, we encounter the notion of session affinity, where the load distribution facility recognizes the existence of a session and attempts to direct all requests within that session to the same server, and we also encounter the notion of transaction affinity, in which the load distribution facility recognizes the existence of a transaction, and behaves similarly.

A particular server affinity mechanism can be weak or strong. In a weak affinity mechanism, the system attempts to enforce the desired affinity for the majority of requests most of the time but might not always be able to provide a total guarantee that this affinity is respected. In a strong affinity mechanism, the system guarantees that affinity is always strictly respected and generates an error when it cannot.

ibm.com/redbooks

Next