10.2.7.2.1 Is the Task of Your Application Suitable for Multithreading and/or Multicontexting?
The following table provides a list of questions to help you decide whether your application would be improved if it were multithreaded and/or multicontexted. This list is not comprehensive; your individual requirements will determine other factors that must be considered.
For additional suggestions, we recommend that you consult a multithreaded and/or multicontexted programming publication.
| If the answer to this question . . . | Is YES, then you might consider using . . . |
|---|---|
| Does your client need to connect to more than one application without using the Domains feature? | Multicontexting. |
| Does your client perform the role of a multiplexer within your application? For example, have you designated one machine in your application the “surrogate” for 100 other machines? | Multicontexting. |
| Does your client use multicontexting? | Multithreading. By allocating one thread per context, you can simplify your code. |
| Does your client perform two or more tasks that can be executed independently for a long time such that the performance gains from concurrent execution outweigh the costs and complexities of threads synchronization? | Multithreading. |
| Do you want one server to process multiple concurrent requests? | Multithreading. Assign a value greater than 1 to MAXDISPATCHTHREADS. This value enables multiple clients, each in its own thread, for the server.
|
| Do you want to perform ATMI calls in application-created server thread? | Multithreading. Application-created server thread creates a separate Tuxedo context and associates itself with the context by calling tpappthrinit(3c) (This feature is available from Tuxedo 11g Release 1 (11.1.1.3.0)) |
| If your client or server had multiple threads, would it be necessary to synchronize them after each thread had performed only a little work? | Not using multithreading. |
Parent topic: Design Requirements