BEA Logo BEA Tuxedo Release 7.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using C

How Multithreading and Multicontexting Work in a Server

The events that occur in a server when a multithreaded and multicontexted application is active can be described in three phases:

Start-up Phase

What happens during the start-up phase depends on the value of the MINDISPATCHTHREADS and MAXDISPATCHTHREADS parameters in the configuration file.

If the value of MINDISPATCHTHREADS is . . .

And the value of MAXDISPATCHTHREADS
is . . .

Then . . .

0

> 1

  1. The BEA Tuxedo system creates a thread dispatcher.

  2. The dispatcher calls tpsvrinit() to join the application.

> 0

> 1

  1. The BEA Tuxedo system creates a thread dispatcher.

  2. The dispatcher calls tpsvrinit() to join the application.

  3. The BEA Tuxedo system creates additional threads for handling service requests, and a context for each new thread.

  4. Each new system-created thread calls tpsvrthrinit(3c) to join the application.

Work Phase

In this phase, the following activities occur:

Server-dispatched Threads Are Used

In response to clients' requests for a service, the server dispatcher creates multiple threads (up to a configurable maximum) in one server that can be assigned to various client requests concurrently. A server cannot become a client by calling tpinit().

Each dispatched thread is associated with a separate context. This feature is useful in both conversational and RPC servers. It is especially useful for conversational servers which otherwise sit idle, waiting for the client side of a conversation while other conversational connections are waiting for service.

This functionality is controlled by the following parameters in the SERVERS section of the UBBCONFIG(5) file and the TM_MIB(5).

UBBCONFIG Parameter

MIB Parameter

Default

MINDISPATCHTHREADS

TA_MINDISPATCHTHREADS

0

MAXDISPATCHTHREADS

TA_MAXDISPATCHTHREADS

1

THREADSTACKSIZE

TA_THREADSTACKSIZE

0 (representing the OS default)

Application-created Threads Are Used

Using your operating system functions, you may create additional threads within an application server. Application-created threads may:

Some restrictions govern what you can do if you create threads in your application.

BBL Verifies Sanity of System Processes

The BBL periodically checks servers. If a server is taking too long to execute a particular service request, the BBL kills that server. (If specified, the BBL then restarts the server.) If the BBL kills a multicontexted server, the other service calls that are currently being executed are also terminated as a result of the process being killed.

The BBL also sends a message to any process or thread that has been waiting longer than its timeout value to receive a message. The blocking message receive call then returns an error indicating a timeout.

System Keeps Statistics on Server Threads

For each server, the BEA Tuxedo system maintains statistics for the following information:

Userlog Maintains Thread-specific Information

For each thread in each application, userlog(3c) records the following identifying information:

process_ID.thread_ID.context_ID

Placeholders are printed in the thread_ID and context_ID fields of entries for non-threaded platforms and single-contexted applications.

The TM_MIB(5) supports this functionality in the TA_THREADID and TA_CONTEXTID fields in the T_ULOG class.

Completion Phase

When the application is shut down, tpsvrthrdone(3c) and tpsvrdone(3c) are called to perform any termination processing that is necessary, such as closing a resource manager.

See Also