Skip navigation.

Setting Up a Tuxedo Application

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

About the Configuration File

This topic includes the following sections:


What Is the Configuration File?

Configuring each BEA Tuxedo application is a central task of the administrator. By configuring a file, you are describing your application using a set of parameters that the software interprets to create a viable application. The configuration file is a repository that contains all the information necessary to boot and run an application, such as specifications for application resources, machines, machine groups, servers, available services, interfaces, and so on.

Text and Binary Versions of the Configuration File

The configuration file exists in two versions:


Contents of the Configuration File

The following table lists the nine sections of the configuration file and describes the purpose of each section.


Required or Optional




Defines all system parameters.



Specifies all the machines in your application.



Defines all groups, group names, and group IDs for your application.



Specifies the initial conditions for servers started in the system.



Provides information on services used by the application.



For CORBA environments, provides information on application-wide, default parameters for interfaces used by the application.



Describes the network configuration for a LAN environment.



Describes the network groups available to the application in the LAN environment.



Provides information for data-dependent routing of service requests using FML buffers and views.


The file must also contain a minimum of nine parameters. There are 80 different parameters, and all sections but the first, may contain multiple entries, each with its own selection of parameters. In all sections other than RESOURCES, you can use a default to specify parameters that are included in multiple entries.

You can use the command-line interface or BEA Tuxedo Administration Console to create the binary version of the configuration file (TUXCONFIG). First you need to determine the type of configuration you are defining in the file.


CORBA Administrative Requirements and Performance

This section provides information to assist you in administering your CORBA environment in the BEA Tuxedo system.

Configuring NameManager

Adhering to the following requirements is fundamental to successful CORBA administration.

Reliability Requirements

This section contains information that will improve CORBA reliability.

Managing Factory Entries

When application servers "die," they often fail to unregister their factories with the NameManager. In some cases, the FactoryFinder may give out object references for factories that are no longer active. This occurs because the servers containing those factories have become unavailable, have failed to unregister their factories with the NameManager, and there is no other server capable of servicing the interface for that factory.

In general, an application factory can restart shortly thereafter, and then offer the factories. However, to ensure that factory entries are not kept indefinitely, the NameManager is notified when application servers die. Upon receipt of this notification, the NameManager may remove those factory entries that are not supported in any currently active server.

Configuring Multiple NameManagers and FactoryFinders

At a minimum, two NameManagers, a master and a slave, must be configured in an application, preferably on different machines, to provide querying capabilities for a FactoryFinder. Multiple FactoryFinders can also be configured in an application.

Designating a Master NameManager

A Master NameManager must be designated in the UBBCONFIG file. All registration activities are sent to the Master NameManager. The Master NameManager then notifies the Slave NameManagers about the updates. If the Master NameManager is down, registration/unregistration of factories is disabled until the Master restarts.

Performance Hint

You can optimize FactoryFinder and NameManager performance by running these services on separate servers within the same machine rather than running these services on different machines. This provides a quicker response because it eliminates the need for machine-to-machine communication.

See Also


Skip navigation bar  Back to Top Previous Next