Browse Prior Art Database

Optimum Thread Selection In An OO Application Server

IP.com Disclosure Number: IPCOM000123519D
Original Publication Date: 1998-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 195K

Publishing Venue

IBM

Related People

Hutchison, G: AUTHOR [+2]

Abstract

One of the main reasons for the existence of a Transaction Monitor or Application Server is the sharing, pooling and reuse of resources between individual user transactions.

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

Optimum Thread Selection In An OO Application Server

   One of the main reasons for the existence of a Transaction
Monitor or Application Server is the sharing, pooling and reuse of
resources between individual user transactions.

   A typical 'new age' application server is Component Broker
(CB).  CB will pool certain resources for the sharing and reuse of
user transactions.  A prime example is DB2* database connections
which are slow to acquire but can be subsequently reused for many
transactions.

   A CB server runs a number of threads within its system,
allocating incoming work to a particular thread for scheduling
within the system.  A concrete problem that currently exists is that
some resources that one would wish to pool and reuse between user
transactions are specifically associated with a particular thread
within the server.  A prime example of such a resource is an Oracle
XA database connection.  These are acquired on a particular thread
within the system and although they can be reused for other
subsequent transactions they require the transaction to be running on
the particular thread the connection is associated with.

   When new transactional work flows to the Application
Server the system receives the work request and schedules a thread
for the work to run on.  However, it is usually not possible to
predict which would be the optimal thread for the work to be
allocated to ie the thread that has the best mixture of
thread-specific resources available for re-use as there is no form of
transaction 'type' associated with the incoming work or information
on what resources it will request in the course of the transaction.

   The method described here selects the optimum thread from
the thread pool for such incoming work.  The method is based on
matching the profile of thread specific resouce use for previous
flows that had the same characteristics as the incoming work and the
profile of thread specific resources attached to each of the threads
available for work scheduling.

   While the example described below is directed to
connection reuse in the Oracle adapter/RDBIM of Component Broker the
technique is generally applicable to all such Corba** based
application/component servers.

   When the request arrives at the CB application server it
is received on a single, port listening, thread.  Corba Object
Services orb interceptors and other 'context' type operations are
called from a common system thread that deals with incoming work to
examine the incoming request.  The various services examine the
'context' of the request and determine the correct context to be
associated with the running request.

   The system then selects a thread for the transaction to
execute on.  From this thread the same set of 'context' services are
called this time to'resume' their context onto the thread the user's
code will run on.  The user's code is then allowed to run on the
thread which now has the correct context as it was flo...