Transaction Execution Thread Affinity Management within a Multi-node Server
Original Publication Date: 2001-Jan-01
Included in the Prior Art Database: 2003-Jun-19
The technique described manages the routing of application requests to the correct execution context within a multi-node server. In a transactional application, when a client makes a call to a server, the request will typically be served by assigning an execution context to that request. The execution context will manage the local transactional updates made by the application logic. These updates may ultimately be coordinated as part of a wider distributed transaction. If the application logic returns control to the client without committing the transaction, then the transactional resources updated in the server will be locked to the execution context. Subsequent calls from the client within the same distributed transaction to the same transactional resources must be served by the same execution context. Even calls to other (so far untouched) resources managed by the same server within the same distributed transaction should be routed to the existing execution context, so as to minimise the number of local nodes within the distributed transaction. There is an affinity between requests and execution contexts for the lives of the transactions. A simple server may just be an operating system process that uses threads within the process to serve requests. This technique has scalability limitations and poor failure isolation characteristics. A more sophisticated server may use multiple processes on multiple cooperating nodes to form a single logical server this level of sophistication is being provided by the CICS/390 support for Enterprise Java Beans. The server must decide where to route each request received. If the request is part of a transaction already being served by some execution context, then the request should be routed to that context. State must be shared between the nodes comprising the server to identify which transactions are associated with which execution context. This state maps transaction identifiers to execution contexts to enable the affinities to be honoured. Entries in this map need only be made when control leaves an execution context and there is an active transaction to come back to. Thus it is up to the execution contexts to add these entries for the routing component to use subsequently.