Browse Prior Art Database

Transaction Execution Thread Affinity Management within a Multi-node Server

IP.com Disclosure Number: IPCOM000014320D
Original Publication Date: 2001-Jan-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 53K

Publishing Venue

IBM

Abstract

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.

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

Page 1 of 2

Transaction Execution Thread Affinity Management within a Multi-node Server

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.

     The lifetime of the affinities recorded in this routing state is limited to the transactions involved. In fact, the affinity must be recorded until such time that no more application requests can be routed to the execution context within the particular transaction - that is until the transaction commences a syncpoint.

     The problem to be addressed is that if information is mistakenly left in the routing map beyond the life of the transaction then, not only does this garbage occupy space in the map, but the freedom to serve subsequent requests to the most...