Browse Prior Art Database

Transaction context affinity management within a multi-node server presenting a single server image

IP.com Disclosure Number: IPCOM000014361D
Original Publication Date: 2001-Jun-16
Included in the Prior Art Database: 2003-Jun-19
Document File: 4 page(s) / 62K

Publishing Venue

IBM

Abstract

A system for ensuring delivery of requests from a client to a specific server in a workload managed server complex is disclosed. The system is used to enable maintenance of what are termed affinities , whereby not all requests made of a server complex may be arbitrarily assigned to available compute power (servers). Instead, temporarily at least, some requests need to return to a particular server, or even thread/task, in order to access resources that are necessarily local to that processor/server or to force serialisation or security requirements usually met by the implicit assumption of a single active processor. For example, in a workload managed server complex with Enterprise JavaBeans* (EJB**) support, EJB server requests, when associated with a particular transaction, are likely to have thereafter an affinity with a particular server. Subsequent related requests (those executing in the same transaction context, for example) must be re-associated with the same transaction resources. A single-threaded implementation of recursive requests being sent to a single transaction and a directory mechanism for sharing the identifiers of executing transactions are assumed. The re-association is mediated by a collection of request pipelines called requeststreams . Each requeststream delivers requests to a specific executing unit (task/thread) from anywhere in the server complex. In particular requests from external clients (external to the server complex) can be routed to appropriate parts of the complex. When a request is routed to an existing processor context (thread/task) the problem of re-association is addressed by a requestsreams join operation. This operation enables requests to be served by a processor task that holds an existing transaction context, while at the same time maintaining a uniform and manageable send/receive interface for requests on a requeststream both for the sender and the processor of a request. Outline of requeststreams

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 4

  Transaction context affinity management within a multi-node server presenting a single server image

A system for ensuring delivery of requests from a client to a specific server in a workload managed server complex is disclosed. The system is used to enable maintenance of what are termed affinities, whereby not all requests made of a server complex may be arbitrarily assigned to available compute power (servers). Instead, temporarily at least, some requests need to return to a particular server, or even thread/task, in order to access resources that are necessarily local to that processor/server or to force serialisation or security requirements usually met by the implicit assumption of a single active processor.

     For example, in a workload managed server complex with Enterprise JavaBeans* (EJB**) support, EJB server requests, when associated with a particular transaction, are likely to have thereafter an affinity with a particular server. Subsequent related requests (those executing in the same transaction context, for example) must be re-associated with the same transaction resources. A single-threaded implementation of recursive requests being sent to a single transaction and a directory mechanism for sharing the identifiers of executing transactions are assumed.

     The re-association is mediated by a collection of request pipelines called requeststreams. Each requeststream delivers requests to a specific executing unit (task/thread) from anywhere in the server complex. In particular requests from external clients (external to the server complex) can be routed to appropriate parts of the complex. When a request is routed to an existing processor context (thread/task) the problem of re-association is addressed by a requestsreams join operation. This operation enables requests to be served by a processor task that holds an existing transaction context, while at the same time maintaining a uniform and manageable send/receive interface for requests on a requeststream both for the sender and the processor of a request.

Outline of requeststreams

     Requeststreams are implemented as objects with the methods (operations) create, join and destroy with additional (modal) methods send and receive that deliver and retrieve requests and their replies through requeststreams. Once created a requeststream accepts a request (from a requester) and sends it to a processor. At some future time a reply is returned for each request sent. The processor may receive requests and send replies, the requester sends requests and receives replies. Although a request is necessarily paired with a reply, pairs may be nested, so that while a processor is servicing a request it may receive another which it needs also to reply to. The pairs are strictly nested, which means that a second request is replied to before the first may be replied to, although this nesting may be broken in the event, for example, of a request or server task failure. Special notification protoco...