Overview

Introduction

Designing an application to use multiple, independent threads provides concurrency within an application and can improve overall throughput. Using multiple threads enables applications to be structured efficiently with threads servicing several independent tasks in parallel. Multithreading is particularly useful when:

There is a set of lengthy operations that do not necessarily depend on other processing.

The amount of data to be shared is small and identifiable.

You can break the task into various activities that can be executed in parallel.

There are occasions where objects must be reentrant.

Historically, industry-wide, multithreaded applications have been complicated to design and implement. The support provided by BEA Tuxedo simplifies this complexity by managing threads within a CORBA server environment.

The BEA Tuxedo software supports server applications that have the following multithreading characteristics (see Figure 4-1):

Server objects can create and monitor their own threads to implement parallelism within a servant method.

Figure 4-1 Multithreaded CORBA Server Application

Generally, the BEA Tuxedo software creates and manages threads on behalf of a server application. Building multithreaded server applications affects how you use the TP Framework, implement servants, and design objects that create their own threads.

The BEA Tuxedo software allows you to implement either the thread-per-request model or a thread-per-object model. Each model is explained in
Threading Models on page 4-5.

Requirements, Goals, and Concepts

Some computer operations take a substantial amount of time to complete. A multithreaded design can significantly reduce the wait time between the request and completion of operations. This is true in situations when operations perform a large number of I/O operations such as when accessing a database, invoking operations on remote objects, or are CPU-bound on a multiprocessor machine. Implementing multithreading in a server process can increase the number of requests a server processes in a fixed amount of time.

The primary requirement for multithreaded server applications is the simultaneous handling of multiple client requests. The motivations for developing this type of server are to:

Simplify program design

This is achieved by allowing multiple server tasks to proceed independently using conventional programming abstractions.

Improve throughput

This is achieved by taking advantage of the parallel processing capabilities of multiprocessor hardware platforms and overlapping computation with communication.

Improve perceived response time

By associating separate threads with different server tasks, clients do not block each other for an extended period of time.

Simplify coding of remote procedure calls and conversations

Some applications are easier to code when you use separate threads to interact with different remote procedure calls (RPCs) and conversations.

Provide simultaneous access to multiple applications

When wrapping legacy applications or databases in a CORBA server, implementations can interact with more than one legacy application at a time.

Reduce the number of servers required

Because one server can dispatch multiple service threads, the number of servers your application requires can be reduced.

However, a multithreaded design is not without cost. In general, multithreaded server applications require more complicated synchronization strategies than single-threaded servers. An application developer must write thread-safe code. Additionally, the overhead of creating a thread to handle a request might be greater than the potential benefit of parallelism. The actual performance of a particular concurrency model depends on the following factors:

Characteristics of requests from the client

Are the requests of long or short duration?

How threads are implemented

Are the threads managed in the operating system kernel, in a library in user space, or some combination of both?

Operating system and network overhead

How much additional overhead is introduced by repeatedly setting up and tearing down connections?

Higher-level system configuration factors

Do replication, dynamic load balancing, or other factors affect performance?

While threading libraries provide the mechanisms for creating concurrency models, developers are ultimately responsible for knowing how to use the mechanisms successfully. By studying design patterns, application developers can master the subtle differences and make better design choices for different situations.

Threading Models

There are a number of different models you can use for designing concurrency in servers. The following sections describe the thread-per-request model, the thread-per-object model, the thread pool, and how the BEA Tuxedo software implements each model. A specific server is designed for either the thread-per-request model or the thread-per-object model.

Thread-Per-Request Model

In this model, each request from a client is processed in a different thread of control. This model is useful when a server typically receives requests of long duration from multiple clients. It is less useful for requests of short duration due to the overhead of creating a new thread for each request. Each time a new request arrives, BEA Tuxedo associates that request with a thread and executes it. Because a multithreaded application server process can host more than one thread at a time, it can simultaneously execute more than one client request at a time. BEA Tuxedo controls the association of a request to a thread, therefore, applications do not need to explicitly create threads unless the applications require a greater degree of control than that provided by BEA Tuxedo.

The thread-per-request model requires that you design your application servers to be thread-safe, which means that you must implement concurrency mechanisms to control access to data that might be shared among multiple server objects. The need to use concurrency control mechanisms increases the complexity of the applications development process. Additionally, if many clients make requests simultaneously, this design can consume a large number of operating system resources.

Thread-Per-Object Model

The thread-per-object model associates each active object in the server process with a single thread at any one time. Each request for an object establishes an association between a dispatch thread and the object. Serial requests for the same object can be serviced by different threads. A specific thread can be shared by multiple objects.

The Thread Pool

Thread pools are a means to reduce the cost of managing threads. At startup and as needed, threads are created, assigned, and released to a pool of available threads where the thread waits until it is needed again to process future requests. Thread pools can be used to support any of the threading models previously described. For example, a thread may be allocated for a request in a thread-per-request model, used for the method execution, and released back to the pool.

Allocating and deallocating threads can be time-consuming and expensive, especially for short-lived requests and objects. Thread pools provide a means of reducing the cost of managing threads. During startup, or as needed, threads are created, assigned, and released by the BEA Tuxedo software to a pool of available threads. A thread exists in the pool and waits until it is needed to process future requests.

The initial and ultimate size of the BEA Tuxedo thread pool for an application server process is controlled through settings in the server configuration file. At startup, the minimum pool size is pre-allocated. As requests arrive to be serviced, the BEA Tuxedo software assigns a thread from the pool to handle the request. If the pool does not contain an available thread to process the request and the pool has not been filled, the BEA Tuxedo software creates a new thread to handle the request. If a request arrives when there are no threads available in the pool, and no new threads can be created, the request will be queued until a thread is available.

Thread pools are appropriate for situations in which you want to limit the amount of system resources that can be consumed for server threading. When a thread pool is used, client requests are executed concurrently until the number of simultaneous requests exceeds the number of threads in the pool.

The BEA Tuxedo thread pool has the following characteristics and behavior:

You can set the maximum size of the pool as a BEA Tuxedo administration function. You can adjust the size of this pool without making changes to the application itself.

The BEA Tuxedo software allocates threads from the pool as necessary. The threads are used during the processing of a request, and are then released back to the pool.

Threads can be serially reused for servicing multiple requests and multiple objects.

Reentrant Servants

The BEA Tuxedo software provides the capability for an object to invoke operations on itself recursively. Using this capability requires a great deal of care in how you implement an object, because the application code must employ the operating system concurrency mechanisms needed to control access to shared state data. In some cases, such as with objects that implement the Process or Distribution Adapter design patterns, there is little or no shared state for an object, and it is relatively easy to support reentrancy.

BEA Tuxedo software also allows you to enable or prohibit reentrant method invocations on an active object. Reentrancy is disabled by default. If a request for an active object is received while the object is currently executing another request in a different thread, the following rules apply:

If the _is_reentrant method returns TRUE, a new thread is allocated from the pool and the request is dispatched to the appropriate method using the same servant instance. It is the responsibility of the servant implementation code to ensure the integrity of the state of the object when multiple threads interact with it.

If the _is_reentrant method returns FALSE, a new instance of the servant is created and the method is dispatched to the new instance. This instance is not automatically deleted. Future reentrant requests may be dispatched to either instance.

Note:

The reentrant servant mechanism is available only when a server is started with the PER_REQUEST concurrency strategy specified.

For information about using this method, see the CORBA Programming Reference.

The Current Object

One of the most important attributes of a multithreaded CORBA server application environment is ensuring that the Current object is used and managed correctly. This ensures behavior such as the following:

Individual threads function within the correct transaction and security contexts.

The Current object behaves correctly when accessed from different threads.

The BEA Tuxedo product conforms to the multithreading model defined by the ORB Portability Specification, published by the OMG, which has been incorporated into the OMG CORBA specification. In the BEA Tuxedo product, operations on interfaces derived from CORBA::Currenthave access to the state associated with the thread in which operations are invoked, not to the state associated with the thread from which the Current object was obtained. The reason for this behavior is twofold:

Prevents one thread from manipulating the state of another thread

Avoids the need to obtain and narrow a new Current object in the thread context for each method

When used in a multithreaded environments, the behaviors of the following objects are consistent with the ORB Portability Specification:

CosTransactions::Current

SecurityLevel1::Current

SecurityLevel2::Current

PortableServer::Current

For example, when an application passes a transaction from one thread to another, the application should not use the CosTransactions::Currentobject. Instead, the application passes the CosTransactions::Controlobject to the other thread. To pass the CosTransctions::Currentobject would only allow the receiving thread to gain access to the transaction state associated with that thread.

Mechanisms for Supporting Multithreaded CORBA Servers

This section provides an overview of the following tools, APIs, and administrative capabilities in BEA Tuxedo CORBA that support multithreaded server applications:

Context Services

You can choose to create and manage your own threads in your object implementations. Other threads are managed automatically by the BEA Tuxedo CORBA software. The BEA Tuxedo CORBA software maintains context information internally for each thread that it creates and maintains. This required context information is used during the processing of CORBA requests. Since BEA Tuxedo CORBA has no knowledge of when an application creates and deletes its own threads, the context services mechanism allows programmers to initialize their own threads correctly, prior to calling BEA Tuxedo services, and to release any context resources that are no longer needed when a thread is deleted.

The following set of ORB methods satisfies the thread management requirements. Together these are called context services:

ORB::get_ctx()

When an object creates a thread, the object invokes this operation on the ORB to obtain system context information that the object can pass onto the thread. This operation must be called from a thread that already has a context. For example, the thread in which a method was dispatched will already have a context. For information about using this operation, see ORB::get_ctx() in the CORBA Programming Reference.

ORB::set_ctx()

When an object spawns a thread, the spawned thread typically retrieves the context information from the thread that invoked the get_ctx method. The spawned thread then uses the retrieved context information when invoking ORB::set_ctx to set the system context in which the spawned thread should execute. For information about using this operation, see ORB::set_ctx() in the CORBA Programming Reference.

ORB::clear_ctx()

When a spawned thread has completed its work, the thread invokes this method to dissociate itself from the system context. For information about using this operation, see ORB::clear_ctx() in the CORBA Programming Reference.

ORB::inform_thread_exit()

When a thread has completed its work, the thread invokes this method to inform the BEA Tuxedo system that resources associated with an application-managed thread can be released. For information about using this operation, see ORB::inform_thread_exit() in the CORBA Programming Reference.

Classes and Methods in the TP Framework

These classes and methods in the BEA Tuxedo TP Framework support multithreaded server applications:

ServerBase class

To override the default implementations of the ServerBase class, an application developer can create a class that derives from ServerBase. In addition to ServerBase methods already supported, these methods are provided to support the implementation of multithreaded server applications:

create_servant_with_id()

thread_initialize()

thread_release()

These methods allow you to obtain a high-degree of granularity of control over the multithreading characteristics of your application. For information on how to use these methods see ServerBase Class in the CORBA Programming Reference.

Tobj_ServantBase class

This class provides these methods to support multithreaded server applications:

Capabilities in the Build Commands

The buildobjserver and buildobjclient commands include the following thread-management capabilities.

The buildobjserver command includes platform-specific thread library support so that server applications are compatible with the multithreading support in the BEA Tuxedo software.

The buildobjserver command includes command-line options for building multithreaded or single-threaded server applications.

The buildobjclient command includes platform-specific thread library support so that client applications can be compatible with the multithreading support provided in the BEA Tuxedo software.

Tools for Administration

The BEA Tuxedo system employs configuration files to assemble and run applications. Typically, the application developer creates these files, and BEA Tuxedo system administrators modify the contents of the file as necessary to satisfy application and system requirements.

The control parameters associated with the support of threads specify the following:

Whether a server should be single-threaded or multithreaded

The size of the thread pool available for dispatching methods on objects

Running Single-threaded Server Applications in a Multithreaded System

The default behavior of the threading support provided in BEA Tuxedo CORBA is to emulate a single-threaded server support environment. To run a single-threaded CORBA application in a multithreaded environment, you do not need to change the server application code or the configuration files. However, before you run an existing single-threaded application, you must rebuild it using the buildobjserver and buildobjclient commands. If you do not specifically enable multithreading for a server application, the application runs as a single-threaded server.

Platform-specific Thread Libraries

Server applications generated by the buildobjserver command are compiled using the correct platform-specific compiler settings, and are linked using the correct platform-specific thread support libraries. This ensures compatibility with the shared libraries provided by the BEA Tuxedo software.

Specifying Multithreaded Support

When you create a CORBA server application to support multithreading, you must specify the -t option on the buildobjserver command when you build the application. At run time, the BEA Tuxedo system verifies compatibility between the executable program and the threading model selected in the CORBA server application configuration file UBBCONFIG. For information on how to set the threading model in the UBBCONFIG file, see
Sample UBBCONFIG File on page 4-36.

Note:

When you specify -t in your build of a CORBA server application, you should set the MAXDISPATCHTHREADS parameter in the UBBCONFIG file to a value greater than 1; otherwise, the CORBA server application will run as a single-threaded server.

Note:

Multithreaded joint client/server implementations are not supported.

If you attempt to start a single-threaded executable with an incompatible threading model specification in the configuration file, these events occur:

The BEA Tuxedo software records a warning in the log file.

The server executable program is started as a single-threaded server.

Specifying an Alternate Server Class

If you implement your own Server class, inheriting from the ServerBase class, you must specify your alternate Server class in the buildobjserver command using the -b option. The buildobjserver command provides the following syntax to support the -b option:

In the preceding syntax, the value for bootserverclass specifies the C++ class to be used when the CORBA server application is booted. If you do not specify the -b option, the BEA Tuxedo system creates an instance of the class named Server.

When you specify the -b option, the Tuxedo system creates a main function for the alternate server class, and your project must supply a header file with the name you specified for bootserverclass on the -b option. The header file contains the definition of the alternate C++ class. This alternate Server class must inherit from the ServerBase class.

For example, if the command line specifies -b AslanServer, the application project must supply an AslanServer.h file. The AslanServer.h file is an example of a bootserverclass.h file. A bootserverclass file provides logic similar to this code sample:

Using the buildobjclient Command

When you use the buildobjclient command to create a client application executable program, the application is compiled using the correct platform-specific compiler settings and linked using the correct thread support libraries for your operating system. This ensures that clients are compatible with the shared libraries provided by the BEA Tuxedo software.

Creating Non-reentrant Servants

Before you can run any CORBA server application in the BEA Tuxedo CORBA environment, you must build it using the buildobjserver command.

Use the buildobjserver-t option to inform the BEA Tuxedo system that the CORBA server application is thread safe. The -t option indicates that the application does not employ shared context data or other programming constructs that are not thread safe. If you run single-threaded applications that are not thread safe in a multithreaded environment, you risk data corruption.

If you update configuration files for an application to enable multithreading support, but the application code has not been updated to indicate that the servant implementation can support reentrancy, note the following:

Methods are executed in arbitrary threads assigned by the BEA Tuxedo system.

Servant implementation code does not necessarily protect an object from concurrent access to its state. However, active servants are limited to a single thread of execution at a time.

You cannot assume that a method is executed in a specific thread. Do not use storage that depends on or is tied to a specific thread.

Do not assume that the servant's activate_object or deactivate_object methods are executed in the same thread as the request in which they were originally invoked.

Additional application-managed threads can be created within a servant method. Your object implementations must ensure that threads are created, handled, and destroyed properly.

An application-managed thread can include invocations on other objects.

Do not use signals for synchronization; the mixing of signals and threads is not supported.

Note:

The SIGKILL signal to terminate a process is supported. The use of SIGIO is not supported in BEA Tuxedo CORBA for single or multithreaded applications.

Request-level interceptors are invoked by BEA Tuxedo CORBA through the same thread used by the method.

Creating Reentrant Servants

To create a multithreaded reentrant servant:

Build the CORBA server application using the buildobjserver command with the -t option, and modify the UBBCONFIG server configuration file for the application.

Update the CORBA server application code to enable reentrancy using the TobjServantBase::_is_reentrant method.

Start the server using the thread-per-request threading model, by specifying CONCURR_STRATEGY = PER_REQUEST in the UBBCONFIG file.

If you do create a multithreaded, reentrant servant, the implementation code for that object must protect the state of the object, in order to ensure its integrity while multiple threads interact with it.

Considerations for Client Applications

There are considerations for CORBA client applications running in the BEA Tuxedo environment:

Multithreaded CORBA clients using IIOP are supported.

Multithreaded native CORBA clients are not supported.

A multithreaded CORBA client is limited to a single bootstrap object.

A multithreaded CORBA client is limited to a single logon.

CORBA clients using stub-based invocation are supported.

CORBA clients using the Dynamic Invocation Interface (DII) are not supported.

Building and Running the Multithreaded Simpapp Sample Application

About the Simpapp Multithreaded Sample

The BEA Tuxedo software provides a multithreaded CORBA sample application, consisting of a client program and a CORBA server program. The server receives an alphabetic string from the client and returns the string in uppercase and lowercase letters. The multithreading capability of simpapp_mt provides parallel processing. Through this parallelism, a single server process can handle concurrent requests from multiple clients for multiple objects or for a single object.

Note:

The client application in the simpapp_mt sample is not a multithreaded client application.

How the Sample Application Works

The purpose of a multithreaded server is to handle multiple requests from one or more clients in a parallel manner. The simpapp_mt sample application is a CORBA application that demonstrates multithreading functionality, by using the buildobjserver -t command-line option and using the UBBCONFIG file to specify concurrency strategy.

The simpapp_mt sample first creates a server process named SimplePerObject and secondly a server process named SimplePerRequest. The client communicates first with the SimplePerRequest server and then with the SimplePerObject server.

The thread-per-request server implementation for SimplePerRequest demonstrates the use of a user-defined server class that implements thread initialization methods. The SimplePerRequest server process handles each request from a client in a separate thread of control. Each time a new request arrives, a thread is allocated from the thread pool to handle the request. Once the request has been processed and the reply sent, the thread is released back to the pool. This model is useful for servers that handle long-duration requests from multiple clients.

The simpapp_mt sample application provides an implementation of a CORBA object that has the following methods:

The to_upper method accepts a string from the client application and converts it to uppercase letters.

The to_lower method accepts a string from the client application and converts it to lowercase letters.

The forward_upper method creates an application-managed thread to another instance of the server and forwards the request received from the client to the new server instance to convert the string to uppercase letters.

The forward_lower method creates another instance of the Simple object and forwards the request received from the client to the new instance to convert the string to lowercase letters.

Figure 4-2 shows the operation of the simpapp_mt sample application, employing both the thread-per-object and thread-per-request threading models.

Figure 4-2 simpapp_mt Sample Application

OMG IDL Code for the Simpapp Multithreaded Sample Application

The simpapp multithreaded sample application described in this chapter implements the CORBA interfaces listed in the following table.

Interface

Description

Action

SimplePerRequestFactory

Creates object references to the Simple object

find_simple()

SimplePerObjectFactory

Creates object references to the Simple object

find_simple()

Simple

Converts the case of a string

to_upper()

to_lower()

forward_upper()

forward_lower()

Listing 4-2 shows the content of the simple.idl file, describing the CORBA interface in the simpapp_mt sample application.

How to Build and Run the Sample Application

This section leads you, step-by-step, through the process of building and running the simpapp_mt sample application. The flowchart summarizes the process and following sections explain how to perform the tasks.

Figure 4-3 Process for Building and Running simpapp_mt

Setting the TUXDIR Environment Variable

Before building and running the simpapp_mt sample application, ensure that the TUXDIR environment variable is set on your system. Typically, the environment variable is set during the installation process. You should confirm that the environment variable defines the correct directory location.

The TUXDIR environment variable must be set to the directory path where you installed the BEA Tuxedo software. For example:

Windows

TUXDIR=D:\TUXDIR

UNIX

TUXDIR=/usr/local/TUXDIR

Verifying the TUXDIR Environment Variable

Before you run the application, perform the following procedure to ensure that the environment variable contains the correct information.

Windows

Execute the echo command to show the setting of TUXDIR:

prompt> echo %TUXDIR%

UNIX

Execute the ksh command at the prompt to launch the Korn shell.

Execute the printenv command to show the setting of TUXDIR:

ksh prompt> printenv TUXDIR

Changing the Setting of the Environment Variable

To change the value of the environment variable:

Windows

Execute the set command to set a new value for TUXDIR:

prompt> set TUXDIR=directorypath

UNIX

At the system prompt, execute the ksh command to launch the Korn shell.

At the ksh prompt, enter the export command to set the value for the TUXDIR environment variable:

ksh prompt> export TUXDIR=directorypath

Creating a Working Directory for the Sample Application

Note:

The technique of using a work directory is recommended so that you can see what additional files are created when you run the simpapp multithreaded sample. After you execute the runme command, compare the set of files in the installation directory to the set of files in your work directory.

The files required for the simpapp multithreaded sample application are in the following directories:

Windows

%TUXDIR%\samples\corba\simpapp_mt

UNIX

$TUXDIR/samples/corba/simpapp_mt

Create a working directory containing all of the simpapp multithreaded files.

Windows

You can use Windows Explorer to create a copy of the simpapp_mt directory, or you can use the command prompt as follows:

CORBA client program source code for the simpapp_mt sample application.

simple_per_object_i.cpp

Source code that includes implementations for Simple and SimplePerObjectFactory servants that are to be included in a server. The CORBA server is started using a thread-per-object concurrency strategy.

simple_per_object_i.h

Source code file for declaring Simple and SimplePerObjectFactory servants to be included in a server.

Source code that includes implementations for Simple and SimplePerRequestFactory servants that are to be included in a reentrant server. The reentrant CORBA server is started using a thread-per-request concurrency strategy.

simple_per_request_i.h

Source code file for declaring Simple and SimplePerRequestFactory servants to be included in a reentrant server.

An example of a bootserverclass.h file, containing the declarations required for the user-defined Server class in the simpapp_mt sample application.

thread_macros.cpp

Platform-independent thread convenience macros that support the simpapp_mt sample application.

thread_macros.h

Source code file for declaring all the classes and variables for thread convenience macros.

Checking Permissions on All the Files

To build and run the simpapp_mt sample application, you must have user and read permissions on all the files you copied into your working directory. Check the permissions, and change the permissions if required.

Note:

Ensure that the make utility is in your path.

Windows

> attrib -R /S *.*

UNIX

> /bin/ksh

> chmod u+r work_directory/*.*

Executing the runme Command

This section describes the steps required to execute the application end-to-end. Enter the runme command as follows:

Windows

> cd work_directory

> ./runme

UNIX

> /bin/ksh

> cd work_directory

> ./runme.ksh

The runme command automates the following steps:

Checks the TUXDIR environment variable.

Sets the environment variables that are used by this application.

Ensures that the proper bin directories are in the PATH.

If this is not the first time this script has been run, removes unneeded files from the directory.

Creates a directory to capture the results from running this script.

Creates a setenv.ksh file (UNIX) or setenv.bat file (Windows) so that you can build and run this sample step-by-step.

Creates the ubb configuration file for this sample.

Creates a file containing the user input for the client.

Creates a file with the expected output from the client.

Builds the sample.

Loads the configuration file.

Starts the thread-per-object server.

Starts the thread-per-request server.

Runs the client and captures the output.

Compares the output with the expected output.

Shuts down the server application.

Captures logs that are generated when you run the sample.

Saves the results.

Informs the user whether the sample ran successfully.

The simpapp_mt sample application prints the following messages while executing the runme command:

Multithreaded CORBA Server Application Administration

Specifying Thread Pool Size

The MAXDISPATCHTHREADS and MINDISPATCHTHREADS parameters for specifying the maximum and minimum sizes of the thread pool are in the SERVERS section of the UBBCONFIG file. For examples of how to specify these parameters, see Listing 4-4. A multithreaded CORBA application uses these values to create and manage the thread pool.

MAXDISPATCHTHREADS

The MAXDISPATCHTHREADS parameter determines the maximum number of concurrently dispatched threads that each server process can spawn. When specifying this parameter, consider the following:

The value for MAXDISPATCHTHREADS determines the maximum size the thread pool can grow to be, as it increases in size to accommodate incoming requests.

The default value for MAXDISPATCHTHREADS is 1. If you specify a value greater than 1, the system creates and uses a special dispatcher thread. This dispatcher thread is not included in the number of threads determining the maximum size of the thread pool.

Note:

If you specify a value greater than 1 for MAXDISPATCHTHREADS and do not supply a value for the CONCURR_STRATEGY threading model parameter, the threading model for the application defaults to thread-per-object. For a discussion of the CONCURR_STRATEGY threading model parameter, see Specifying a Threading Model.

Specifying a value of 1 for the MAXDISPATCHTHREADS parameter indicates that the CORBA server application should be configured as a single-threaded server.

Note:

When you build a multithreaded CORBA server application specifying buildobjserver-t, that server is capable of running in multithreaded mode. To run as a multithreaded CORBA server application, the MAXDISPATCHTHREADS parameter in the UBBCONFIG file must be set to a value greater than 1; if it is not, the server application will run in single-threaded mode.

The value you specify for the MAXDISPATCHTHREADS parameter must not be less than the value you specify for the MINDISPATCHTHREADS parameter.

The operating system resources limit the maximum number of threads that can be created in a process. MAXDISPATCHTHREADS should be less than that limit, minus the number of application managed threads that your application requires.

The value of the MAXDISPATCHTHREADS parameter affects other parameters. For example, the MAXACCESSORS parameter controls the number of simultaneous accesses to the BEA Tuxedo system, and each thread counts as one accessor. For a multithreaded server application, you must account for the number of system-managed threads that each server is configured to run. Asystem-managedthreadis a thread that is started and managed by the BEA Tuxedo software, as opposed to threads started and managed by an application. Internally, BEA Tuxedo manages a pool of available system-managed threads. When a client request is received, an available system-managed thread from the thread pool is scheduled to execute the request. When the request is completed, the system-managed thread is returned to the pool of available threads.

For example, if that you have 4 multithreaded servers in your system and each server is configured to run 50 system-managed threads, the accessor requirement for these servers is the sum total of the accessors, calculated as follows:

50 + 50 + 50 + 50 = 200 accessors

MINDISPATCHTHREADS

Use the MINDISPATCHTHREADS parameter to specify the number of server dispatch threads that are started when the server is initially booted. When you specify this parameter, consider the following:

The value for MINDISPATCHTHREADS determines the initial allocation of threads in the thread pool.

The separate dispatcher thread that is created when MAXDISPATCHTHREADS is greater than 1 is not counted as part of the MINDISPATCHTHREADS limit.

The value you specify for MINDISPATCHTHREADS must not be greater than the value you specify for MAXDISPATCHTHREADS.

The default value for MINDISPATCHTHREADS is 0.

Specifying a Threading Model

To specify a threading model, you set the CONCURR_STRATEGY parameter which is defined in the SERVERS section of the UBBCONFIG file.

Use the CONCURR_STRATEGY parameter to specify the threading model a multithreaded CORBA server application is to use. The CONCURR_STRATEGY parameter accepts either of these values:

CONCURR_STRATEGY = PER_REQUEST

CONCURR_STRATEGY = PER_OBJECT

When you specify CONCURR_STRATEGY = PER_REQUEST to employ the thread-per-request model, each invocation on the CORBA server application is assigned to an arbitrary thread from the threads pool.

When you specify CONCURR_STRATEGY = PER_OBJECT to employ the thread-per-object model, each active object is associated with a single thread at any one time. Each request for an object establishes an association between a dispatch thread and the object.

If the value for MAXDISPATCHTHREADS is greater than one and you do not specify a value for CONCURR_STRATEGY, the threading model is set to PER_OBJECT.

Specifying the Number of Active Objects

Use the MAXOBJECTS parameter to specify the maximum number of objects per machine to be accommodated in the Active Object Map tables in the bulletin board. You can set this value in either the RESOURCES section or the MACHINES section of the configuration file. The MAXOBJECTSnumber in the RESOURCES section is a system-wide setting. Use the MAXOBJECTSnumber in the MACHINES section to override the system-wide setting on a per-machine basis.

For a system-wide setting, specify:

*RESOURCES MAXOBJECTS number

To override a system-wide setting for a specific machine, specify:

*MACHINES MAXOBJECTS = number

The value for number is limited only by the resources of your operating system.

Sample UBBCONFIG File

Listing 4-4 shows a the UBBCONFIG file for the BEA Tuxedo Threads sample application. The threads-related parameters are presented in boldface text.

Note:

The value for the MAXOBJECTS parameter affects the operation of a multithreaded server. However, this parameter is not specific to multithreaded servers, since it also affects the operation of single-threaded servers. Increasing the value for MAXOBJECTS results in the consumption of additional system resources for any server.