This topic includes the following sections:
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.
The configuration file exists in two versions:
UBBCONFIG
file is a text version of the configuration file, created and edited with any text editor. Except for sample configuration files distributed with BEA Tuxedo sample applications, no UBBCONFIG
file is provided. You must create a UBBCONFIG
file for each new application. The syntax used for entries in the file is described in UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.Note: | The BEA Tuxedo software provides three sample UBBCONFIG files—ubbshm , ubbmp , and ubbsimple —as part of the bankapp and simpapp applications. (See Tutorials for Developing BEA Tuxedo ATMI Applications.) |
TUXCONFIG
file is a binary version of the configuration file, created from the text version by the tmloadcf(1) command. Before tmloadcf
is executed, the environment variable TUXCONFIG
must be set to the full pathname of the device or system file where TUXCONFIG
is to be loaded. If necessary, many parameters in TUXCONFIG
can be changed while the application is running by using tmconfig, wtmconfig(1) or the MIB.
The following table lists the nine sections of the configuration file and describes the purpose of each section.
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.
This section provides information to assist you in administering your CORBA environment in the BEA Tuxedo system.
Adhering to the following requirements is fundamental to successful CORBA administration.
"find"
request is received from an application. NameManagers, on the other hand, attempt to communicate with each other when they boot. FactoryFinders do not communicate with each other except when a request is received to find a factory that is in a remote domain.This section contains information that will improve CORBA reliability.
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.
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.
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.
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.