Creating CORBA Server Applications

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Creating Multithreaded CORBA Server Applications

This topic includes the following sections:

 


Overview

This topic includes the following sections:

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:

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

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

Generally, the Oracle 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 Oracle 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:

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:

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 Oracle 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, Oracle 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. Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle 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 Oracle Tuxedo thread pool has the following characteristics and behavior:

Reentrant Servants

The Oracle 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.

Oracle 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:

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:

The Oracle 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 Oracle 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.

Mechanisms for Supporting Multithreaded CORBA Servers

This section provides an overview of the following tools, APIs, and administrative capabilities in Oracle 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 Oracle Tuxedo CORBA software. The Oracle 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 Oracle 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 Oracle 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:

Classes and Methods in the TP Framework

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

Capabilities in the Build Commands

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

Tools for Administration

The Oracle Tuxedo system employs configuration files to assemble and run applications. Typically, the application developer creates these files, and Oracle 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-36.

Running Single-threaded Server Applications in a Multithreaded System

The default behavior of the threading support provided in Oracle 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.

 


Developing and Building Multithreaded CORBA Server Applications

This topic includes the following sections:

Using the buildobjserver Command

The buildobjserver command supports multithreaded CORBA server applications through the following capabilities:

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 Oracle 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 Oracle 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:

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:

buildobjserver [-v] [-o outfile] [-f {firstfiles|@def-file}] 
[-l {lastfiles|@def-file}] [-r rmname] [-b bootserverclass] [-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 Oracle 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();
};

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 Oracle Tuxedo software.

Creating Non-reentrant Servants

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

Use the buildobjserver -t option to inform the Oracle 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:

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

Creating Reentrant Servants

To create a multithreaded reentrant servant:

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 Oracle Tuxedo environment:

 


Building and Running the Multithreaded Simpapp Sample Application

This topic includes the following sections:

About the Simpapp Multithreaded Sample

The Oracle 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:

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

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.

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();
};

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 Figure 4-3 summarizes the process and following sections explain how to perform the tasks.

Figure 4-3 Process for Building and Running simpapp_mt

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 Oracle 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

  1. Execute the ksh command at the prompt to launch the Korn shell.
  2. Execute the printenv command to show the setting of TUXDIR:
  3. 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

  1. At the system prompt, execute the ksh command to launch the Korn shell.
  2. At the ksh prompt, enter the export command to set the value for the TUXDIR environment variable:
  3.    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:

  1. Create a target working directory for a copy of the simpapp_mt files.
  2. > mkdir work_directory
  3. Copy the simpapp_mt files to the working directory.
  4. > copy %TUXDIR%\samples\corba\simpapp_mt\* work_directory
  5. Change to the working directory.
  6. cd work_directory
  7. List all the files in the working directory.
  8. 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

UNIX

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:

  1. Create a target working directory for a copy of the simpapp_mt files.
  2. > mkdir work_directory
  3. Copy all simpapp_mt files to the working directory.
  4. > cp $TUXDIR/samples/corba/simpapp_mt/* work_directory
  5. Change to the working directory.
  6. cd work_directory
  7. List all the files in the working directory.
  8. $ 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.

Table 4-1 simpapp_mt Files 
File
Description
makefile.mk
(UNIX) Makefile for the simpapp_mt sample application. Use this file to build the application.
makefile.nt
(Windows) Makefile for the simpapp_mt sample application. Use this file to build the application.
Readme.txt
Readme file that provides information about building and running the simpapp_mt sample application.
runme.cmd
(Windows) Command file for building and running the simpapp_mt sample application.
runme.ksh
(UNIX) Korn shell script for building and running the simpapp_mt sample application.
simple.idl
Object Management Group (OMG) Interface Definition Language (IDL) code that declares the SimplePerRequestFactory, SimplePerObjectFactory, and Simple interfaces.
simple_client.cpp
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.
simple_per_object_server.cpp
CORBA server program source code for the simpapp_mt sample application, thread-per-object concurrency strategy. Set CONCURR_STRATEGY = PER_OBJECT in the UBBCONFIG file.
simple_per_request_i.cpp
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.
simple_per_request_server.cpp
CORBA server program source code for the simpapp_mt sample application, thread-per-request concurrency strategy. Set CONCURR_STRATEGY = PER_REQUEST in the UBBCONFIG file.
simple_per_request_server.h
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:

  1. Checks the TUXDIR environment variable.
  2. Sets the environment variables that are used by this application.
  3. Ensures that the proper bin directories are in the PATH.
  4. If this is not the first time this script has been run, removes unneeded files from the directory.
  5. Creates a directory to capture the results from running this script.
  6. Creates a setenv.ksh file (UNIX) or setenv.bat file (Windows) so that you can build and run this sample step-by-step.
  7. Creates the ubb configuration file for this sample.
  8. Creates a file containing the user input for the client.
  9. Creates a file with the expected output from the client.
  10. Builds the sample.
  11. Loads the configuration file.
  12. Starts the thread-per-object server.
  13. Starts the thread-per-request server.
  14. Runs the client and captures the output.
  15. Compares the output with the expected output.
  16. Shuts down the server application.
  17. Captures logs that are generated when you run the sample.
  18. Saves the results.
  19. Informs the user whether the sample ran successfully.

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.

Table 4-2 Files Created in the Working Directory 
File
Description
simple_c.cpp
Created by the idl command for the simple.idl file. This module contains the client stub function for the Simple and SimplePerRequestFactory interface.
simple_c.h
Created by the idl command for the simple.idl file. This module contains definitions and prototypes for the Simple and SimplePerRequestFactory interfaces.
simple_s.cpp
Created by the idl command for the simple.idl file. This module contains the skeleton functions for the Simple_i and SimplePerRequestFactory_i implementations.
simple_s.h
Created by the idl command for the simple.idl file. This module contains definitions and prototypes for the skeleton classes for the Simple_i and SimplePerRequestFactory_i interfaces.
simple_client
Created by the buildobjclient command for the simple_c.cpp and simple_client.cpp files.
simple_per_object_server
Created by the buildobjserver command for the simple_c.cpp, simple_s.cpp, simple_per_object_i.cpp, simple_per_object_server.cpp, and thread_macros.cpp files.
simple_per_request_server
Created by the buildobjserver command for the simple_c.cpp, simple_s.cpp, simple_per_request_i.cpp, simple_per_request_server.cpp, and thread_macros.cpp files.
results directory
Created by the runme command to capture the results from running this script.
adm directory
Created by the runme command to contain the security encryption key database file.

Table 4-3 Files Created in the Results Directory  
Files
Description
input
Created by the runme command to store the input that the runme command provides to the C++ client application.
output
Created by the runme command to contain the output when the runme command executes the C++ client application.
expected_output
Created by the runme command to contain the expected output when the runme command is executed. The output file is compared to determine whether the test passed or failed.
log
Created by the runme command to contain the output generated by the runme command. If the command fails, check this file and the ULOG file for errors.
setenv.cmd
(Windows) Command file to set up environment variables required to build and run the simpapp_mt sample application step-by-step.
setenv.ksh
(UNIX) Command file to set up environment variables required to build and run the simpapp_mt sample application step-by-step.
stderr
Contains messages generated by tmboot. If the -noredirect server option is specified in the UBBCONFIG file, the fprintf method sends the output to this file.
stdout
Contains messages generated by tmboot. If the -noredirect server option is specified in the UBBCONFIG file, the fprintf method sends the output to this file.
tmsysevt.dat
Generated by the tmboot command in the runme command. It contains filtering and notification rules used by the TMSYSEVT process.
tuxconfig
A binary version of the configuration file.
ubb
UBBCONFIG file for the simpapp_mt sample application.
ULOG.date
ULOG file for storing run-time errors.

Running the Sample Application Step-by-Step

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:

  1. Set the environment variables.
  2. Windows

    > ..\results\setenv

    UNIX

    > ../results/setenv.ksh
  3. Execute tmboot -y to launch the application. Information similar to the following is displayed:
  4. >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.

Table 4-4 Server Processes Started by tmboot 
Process
Description
TMSYSEVT
System EventBroker.
TMFFNAME
TMFFNAME server processes:
  • Master NameManagerTMFFNAME server process started when you specify both the -N option and the -M option.
  • SLAVE NameManagerTMFFNAME server process started when you specify only the -N option.
  • FactoryFinder object—a TMFFNAME server process started with the -F option contains this object.
simple_per_object_server
Started as a thread-per-object server.
simple_per_request_server
Started as a reentrant thread-per-request server.
ISL
IIOP listener process.

  1. Execute the client application.
  2. Windows

    > .\simple_client

    UNIX

    > ./simple_client

When you execute the client application, messages similar to the following in Listing 4-3 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

Shutting Down the Sample Application

Before running another sample application, you should shut down the simpapp_mt sample application and eliminate all unwanted files from the working directory.

  1. To end the application, run the tmshutdown -y command. Information similar to the following is displayed:
  2. >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.
  3. Restore the working directory to its original state.
  4. Windows

    > ..\results\setenv
    > make -f clean

    UNIX

    > ../results/setenv.ksh
    > make -f makefile.mk clean

 


Multithreaded CORBA Server Application Administration

This topic includes the following sections:

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 of the MAXDISPATCHTHREADS parameter affects other parameters. For example, the MAXACCESSORS parameter controls the number of simultaneous accesses to the Oracle 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 Oracle Tuxedo software, as opposed to threads started and managed by an application. Internally, Oracle 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:

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:

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.

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 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:

*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 Oracle 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_OBJECT
RESTART = N
simple_per_request_server
SRVGRP = APP_GRP2
SRVID = 2
MINDISPATCHTHREADS = 10
MAXDISPATCHTHREADS = 100
CONCURR_STRATEGY = PER_REQUEST
RESTART = N
ISL
SRVGRP = SYS_GRP
SRVID = 5
CLOPT = "-A -- -n //sunbstar:2468 -d /dev/tcp"
*SERVICES

  Back to Top       Previous  Next