Monitoring Multithreaded and Multicontexted Applications


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Administering a BEA Tuxedo Application at Run Time \| Local Topics \| Previous Topic \| Next Topic \| Contents

While monitoring a multithreaded application, keep in mind that individual threads are not visible to an administrator.
You can get MIB statistical reports for various aspects of your multithreaded and/or multicontexted application by running the tmadmin(1) command interpreter. Here are a few examples of the information you can request for a multithreaded application:
- Count of client contexts per client process and a separate entry for each client context (obtained by running the tmadmin pclt command).
- Count of dispatched services per server process and, optionally, information about each context (obtained by running tmadmin/psr, optionally in verbose mode).
When the BBL checks clients, it verifies that a process is alive. If a process has died, the BBL detects the process death. If an individual thread within a process has died, however, the death of the thread is not detected by the BBL.
Therefore application programmers should keep in mind the possibility that individual threads within a process may die. If one thread dies and a signal is issued, the whole process to which the thread belongs usually dies, and that death is detected by the BBL.

If a thread dies as the result of an erroneous call to a thread exit function, however, no signal is generated. If this type of death occurs before the thread calls tpterm(), then the BBL cannot detect the death and does not deallocate the registry table slot for the context associated with the dead thread. (It would not be proper for the BBL to deallocate this registry table slot even if it could detect the death of the thread because, in some application models, another thread might subsequently choose to associate itself with that context.)

There is no solution for this limitation so it is important for programmers to keep it in mind and design their applications accordingly.

How to Retrieve Data About a Multithreaded/Multicontexted Application Using the MIB

Note: The information presented here applies to all multithreaded and/or multicontexted applications, regardless of which administrative tools are being used. The functionality is discussed from the point of view of an administrator using MIB calls, but is the same for an administrator using an interface to the MIB, whether that interface is tmadmin(1) or the BEA Administration Console.

You can obtain information about a multithreaded or multicontexted application by:

Issuing calls to the MIB
Issuing selected tmadmin commands

Information is available in the following locations:

The client section of the bulletin board registry provides an entry for each context. (An entry is created automatically by the BEA Tuxedo system whenever a new context is created through a call to tpinit() in TPMULTICONTEXTS mode.)
The T_SERVERCTXT class of the TM_MIB provides multiple instances of 14 fields if multiple server dispatch threads are active simultaneously. Specifically, the T_SERVERCTXT section includes an instance of each of the following fields for each active sever dispatch thread: