For certain applications, performance and concurrency can be improved by using multithreading and multicontexting together. In other applications, performance can be unaffected or even degraded by using multithreading and multicontexting together. How performance is affected depends on your application.

In some applications it is easier to code different remote procedure calls and conversations in separate threads than to manage them from the same thread.

Your BEA Tuxedo clients can be connected to more than one application at a time.

Because one server can dispatch multiple service threads, the number of servers to start for your application is reduced. This capability for multiple dispatched threads is especially useful for conversational servers, which otherwise must be dedicated to one client for the entire duration of a conversation.

Multithreaded and multicontexted applications are not easy to write. Only experienced programmers should undertake coding for these types of applications.

It is much harder to replicate an error in a multithreaded or multicontexted application than it is to do so in a single-threaded, single-contexted application. As a result, it is more difficult, in the former case, to identify and verify root causes when errors occur.

The task of managing concurrency among threads is difficult and has the potential to introduce new problems into an application.

Testing a multithreaded application is more difficult than testing a single-threaded application because defects are often timing-related and more difficult to reproduce.

Existing code often requires significant re-architecting to take advantage of multithreading and multicontexting. Programmers need to:

• Remove static variables

• Replace any function calls that are not thread-safe

• Replace any other code that is not thread-safe

Because the completed port must be tested and re-tested, the work required to port a multithreaded and/or multicontexted application is substantial.