Creating CORBA Server Applications
This topic includes the following sections:
This topic includes the following sections:
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:
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):
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.
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:
This is achieved by allowing multiple server tasks to proceed independently using conventional programming abstractions.
This is achieved by taking advantage of the parallel processing capabilities of multiprocessor hardware platforms and overlapping computation with communication.
By associating separate threads with different server tasks, clients do not block each other for an extended period of time.
Some applications are easier to code when you use separate threads to interact with different remote procedure calls (RPCs) and conversations.
When wrapping legacy applications or databases in a CORBA server, implementations can interact with more than one legacy application at a time.
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:
Are the threads managed in the operating system kernel, in a library in user space, or some combination of both?
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.
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.
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.
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.
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:
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:
_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.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.
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:
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::Current
have 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:
When used in a multithreaded environments, the behaviors of the following objects are consistent with the ORB Portability Specification:
For example, when an application passes a transaction from one thread to another, the application should not use the CosTransactions::Current
object. Instead, the application passes the CosTransactions::Control
object to the other thread. To pass the CosTransctions::Current
object would only allow the receiving thread to gain access to the transaction state associated with that thread.
This section provides an overview of the following tools, APIs, and administrative capabilities in BEA Tuxedo CORBA that support multithreaded server applications:
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.
These classes and methods in the BEA Tuxedo TP Framework support multithreaded server applications:
ServerBase
classTo 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:
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
classFor information about using these methods, see Tobj_ServantBase Class
in the CORBA Programming Reference.
The buildobjserver
and buildobjclient
commands include the following thread-management capabilities.
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.
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.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:
For more information about threads parameters in the UBBCONFIG
file, see Sample UBBCONFIG File on page 4-38.
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.
This topic includes the following sections:
The buildobjserver
command supports multithreaded CORBA server applications through the following capabilities:
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.
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-38.
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:
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:
buildobjserver [-v] [-o
outfile
] [-f {firstfiles
|@def-file
}]
[-l {lastfiles
|@def-file
}] [-rrmname
] [-bbootserverclass
] [-t]
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:
Listing 4-1 Example of a bootserverclass.h File
// File name: AslanServer.h
#include <Server.h>
class AslanServer : public ServerBase {
public:
CORBA::Boolean initialize(int argc, char** argv);
void release();
Tobj_Servant create_servant(const char* interfaceName);
Tobj_Servant create_servant_with_id(const char* interfaceName,
const char* stroid);
CORBA::Boolean thread_initialize(int argc, char** argv);
void thread_release();
};
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.
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:
activate_object
or deactivate_object
methods are executed in the same thread as the request in which they were originally invoked.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.
To create a multithreaded reentrant servant:
buildobjserver
command with the -t
option, and modify the UBBCONFIG
server configuration file for the application.TobjServantBase::_is_reentrant
method.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.
There are considerations for CORBA client applications running in the BEA Tuxedo environment:
This topic includes the following sections:
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.
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:
to_upper
method accepts a string from the client application and converts it to uppercase letters.to_lower
method accepts a string from the client application and converts it to lowercase letters.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.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
The simpapp multithreaded sample application described in this chapter implements the CORBA interfaces listed in the following table.
Listing 4-2 shows the content of the simple.idl
file, describing the CORBA interface in the simpapp_mt sample application.
Listing 4-2 OMG IDL Code for the simpapp_mt Sample Application
#pragma prefix
"beasys.com"
interface Simple
{
//Convert a string to lower case (return a new string)
string to_lower(in string val);
//Convert a string to upper case (in place)
string to_upper(in string val);
//Use other server to convert string to lower case
string forward_lower(in string val);
//Use other server to convert string to upper case
string forward_upper(in string val);
};
interface SimplePerRequestFactory
{
Simple find_simple();
};
interface SimplePerObjectFactory
{
Simple find_simple();
};
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
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:
Before you run the application, perform the following procedure to ensure that the environment variable contains the correct information.
Execute the echo
command to show the setting of TUXDIR
:
To change the value of the environment variable:
Execute the set
command to set a new value for TUXDIR
:
prompt> set TUXDIR=
directorypath
ksh prompt> export TUXDIR=
directorypath
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:
%TUXDIR%\samples\corba\simpapp_mt
$TUXDIR/samples/corba/simpapp_mt
Create a working directory containing all of the simpapp multithreaded files.
You can use Windows Explorer to create a copy of the simpapp_mt directory, or you can use the command prompt as follows:
>
mkdir
work_directory
>
copy %TUXDIR%\samples\corba\simpapp_mt\*
work_directory
cd
work_directory
prompt> dir
makefile.mk simple_per_object_i.h
makefile.nt simple_per_object_server.cpp
Readme.txt simple_per_request_i.cpp
runme.cmd simple_per_request_i.h
runme.ksh simple_per_request_server.cpp
simple.idl simple_per_request_server.h
simple_client.cpp thread_macros.cpp
simple_per_object_i.cpp thread_macros.h
You can use your user interface tool to create a copy of the simpapp_mt directory, or you can use the command prompt as follows:
>
mkdir
work_directory
>
cp $TUXDIR/samples/corba/simpapp_mt/*
work_directory
cd
work_directory
$ ls
makefile.mk simple_per_object_i.h
makefile.nt simple_per_object_server.cpp
Readme.txt simple_per_request_i.cpp
runme.cmd simple_per_request_i.h
runme.ksh simple_per_request_server.cpp
simple.idl simple_per_request_server.h
simple_client.cpp thread_macros.cpp
simple_per_object_i.cpp thread_macros.h
Table 4-1 lists and describes the simpapp_mt files used to build and run the application.
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.
> attrib -R /S *.*
> /bin/ksh
> chmod u+r work_directory/*.*
This section describes the steps required to execute the application end-to-end. Enter the runme
command as follows:
> cd work_directory
> ./runme
> /bin/ksh
> cd work_directory
> ./runme.ksh
The runme
command automates the following steps:
The simpapp_mt sample application prints the following messages while executing the runme
command:
Testing simpapp_mt
cleaned up
prepared
built
loaded ubb
booted
ran
shutdown
saved results
PASSED
The entire run-time output for the simpapp_mt sample application is stored in the results directory in your working directory. To see the output created at run time, examine the following files:
Table 4-2 and Table 4-3 identify and describe the files created by executing the runme
command.
This section explains how to run the simpapp_mt sample application in step-by-step mode. You must execute the runme
command before running simpapp_mt in step-by-step mode.
Follow the numbered steps to run the simpapp_mt application:
>tmboot -y
Booting all admin and server processes in /work_directory
/results/tuxconfig
Booting admin processes ...
exec BBL -A : process id=212 ... Started.
Booting server processes ...
exec TMSYSEVT -A : process id=289 ... Started.
exec TMFFNAME -A -- -N -M : process id=297 ... Started.
exec TMFFNAME -A -- -N : process id=233 ... Started.
exec TMFFNAME -A -- -F : process id=265 ... Started.
exec simple_per_object_server -A : process id=116 ... Started.
exec simple_per_request_server -A : process id=127 ... Started.
exec ISL -A -- -n //MrBeaver:2468 : process id=270 ... Started.
7 processes started.
>
Table 4-4 describes the server processes started by tmboot
.
When you execute the client application, messages similar to the following are displayed:
Listing 4-3 Messages Displayed When simpapp_mt Client Is Executed
Number of simultaneous requests to post (1-50)?
String to convert using thread-per-request server?
Sending 4 deferred forward_lower requests
forward_lower request #0 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #1 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #2 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #3 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
Sending 4 deferred forward_upper requests
forward_upper request #0 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #1 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #2 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #3 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
String to convert using thread-per-object server?
Sending 4 deferred forward_lower requests
forward_lower request #0 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #1 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #2 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
forward_lower request #3 returned:aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz
Sending 4 deferred forward_upper requests
forward_upper request #0 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #1 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #2 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
forward_upper request #3 returned: AABBCCDDEEFFGGHHIIJJKKLLMMNNOOPPQQRRSSTTUUVVWWXXYYZZ
Before running another sample application, you should shut down the simpapp_mt sample application and eliminate all unwanted files from the working directory.
>tmshutdown -y
Shutting down all admin and server processes in /work_directory
/
results/tuxconfig
Shutting down server processes ...
Server Id = 5 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 2 Group Id = APP_GRP2 Machine = SITE1: shutdown succeeded.
Server Id = 4 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 3 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 2 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Server Id = 1 Group Id = SYS_GRP Machine = SITE1: shutdown succeeded.
Shutting down admin processes ...
Server Id = 0 Group Id = SITE1 Machine = SITE1: shutdown succeeded.
7 processes stopped.
This topic includes the following sections:
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.
The MAXDISPATCHTHREADS
parameter determines the maximum number of concurrently dispatched threads that each server process can spawn. When specifying this parameter, consider the following:
MAXDISPATCHTHREADS
determines the maximum size the thread pool can grow to be, as it increases in size to accommodate incoming requests.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.
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.
MAXDISPATCHTHREADS
parameter must not be less than the value you specify for the MINDISPATCHTHREADS
parameter. 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. A system-managed thread is 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:
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:
MINDISPATCHTHREADS
determines the initial allocation of threads in the thread pool.MAXDISPATCHTHREADS
is greater than 1 is not counted as part of the MINDISPATCHTHREADS
limit.MINDISPATCHTHREADS
must not be greater than the value you specify for MAXDISPATCHTHREADS
.MINDISPATCHTHREADS
is 0. 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:
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
.
For more information on the characteristics of threading models, see Threading Models on page 4-5.
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 MAXOBJECTS
number
in the RESOURCES
section is a system-wide setting. Use the MAXOBJECTS
number
in the MACHINES
section to override the system-wide setting on a per-machine basis.
For a system-wide setting, specify:
To override a system-wide setting for a specific machine, specify:
The value for number
is limited only by the resources of your operating system.
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.
Listing 4-4 Threads Sample Application UBBCONFIG File
*RESOURCES
IPCKEY 55432
DOMAINID simpapp
MAXOBJECTS 100
MASTER SITE1
MODEL SHM
LDBAL N
*MACHINES
"sunstar"
LMID = SITE1
APPDIR = "/rusers1/lyon/samples/corba/simpapp_mt"
TUXCONFIG = "/rusers1/lyon/samples/corba/simpapp_mt/results/tuxconfig"
TUXDIR = "/usr/local/TUXDIR"
MAXWSCLIENTS = 10
MAXACCESSERS = 200
*GROUPS
SYS_GRP
LMID = SITE1
GRPNO = 1
APP_GRP1
LMID = SITE1
GRPNO = 2
APP_GRP2
LMID = SITE1
GRPNO = 3
*SERVERS
DEFAULT:
RESTART = Y
MAXGEN = 5
TMSYSEVT
SRVGRP = SYS_GRP
SRVID = 1
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 2
CLOPT = "-A -- -N -M"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 3
CLOPT = "-A -- -N"
TMFFNAME
SRVGRP = SYS_GRP
SRVID = 4
CLOPT = "-A -- -F"
simple_per_object_server
SRVGRP = APP_GRP1
SRVID = 1
MINDISPATCHTHREADS = 10
MAXDISPATCHTHREADS = 100
CONCURR_STRATEGY = PER_OBJECTRESTART = N
simple_per_request_server
SRVGRP = APP_GRP2
SRVID = 2
MINDISPATCHTHREADS = 10
MAXDISPATCHTHREADS = 100
CONCURR_STRATEGY = PER_REQUESTRESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -n //sunbstar:2468 -d /dev/tcp"
*SERVICES