CORBA 2.6 Programmer's Guide for Java

Interacting with a user who may not respond immediately●
Note: On NonStop systems, threads are not run in separate processors. To take advantage of
parallel processing, use separate processes rather than threads.
Multithreading on NonStop systems is non-preemptive.
Multithreading in Client Applications
One typical use of multithreading in NonStop CORBA client programs is to issue concurrent requests to
one or more objects. When multithreading is not used, operations are synchronous. That is, when a client
performs an operation on an object, it must wait for the response to arrive before doing any further
processing. If a client application creates multiple threads, each thread can perform operations and thus
have concurrent outstanding requests.
The feed program that is part of the Bank sample application contains a multithreaded NonStop
CORBA client program.
Note: You can use the Dynamic Invocation Interface (DII) instead of multithreading to issue
asynchronous requests. In some situations, this may be a desirable alternative to
multithreading. However, using the dynamic invocation interface generally requires more
programming effort than does explicit multithreading.
Multithreading in Server Implementations
The behavior of the ORB with regard to multithreading depends on the setting of the threading policy in
the POA. If the threading policy is set to SINGLE_THREAD_MODEL, client requests are processed
sequentially. Although multiple ORB threads might still be used, only one thread is active on the POA at
any given time.
If you use the default POA threading policy (ORB_CTRL_MODEL), requests can be processed
concurrently, in multiple threads. The NonStop CORBA ORB implements ORB_CTRL_MODEL with
the thread-per-request model; that is, the POA will spawn additional threads as necessary to handle
additional requests, up to the maximum number of available servant threads.
The maximum number of servant threads available in a process defaults to 4097. This value can be
changed with the environment variable max_threads key in the server's profile@ORB entity. (Any
value set in the environment variable overrides the setting in profile@ORB.) The effective maximum
number of threads in a server depends also on the size of each thread's stack (set by the stack_size
key in profile@ORB) and the number of NonStop Kernel threads available in a processor.
With ORB_CTRL_MODEL, the POA initially creates a single thread to handle requests for objects in a
server. When a new request arrives, the POA either reuses an existing thread from the thread pool or
spawns a new thread (if the thread pool is empty and the maximum number of threads has not been
reached) to handle the new request. For a new or reused thread to be activated, the thread processing the
original request must have become blocked or have explicitly released control of the processor. If the
thread does not release control of the processor, the POA thread cannot run and spawn or reuse a thread.