2 About the Configuration File
2.1 What Is the Configuration File?
Configuring each Oracle 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.
2.1.1 Text and Binary Versions of the Configuration File
The configuration file exists in two versions:
- The
UBBCONFIG
file is a text version of the configuration file, created and edited with any text editor. Except for sample configuration files distributed with Oracle Tuxedo sample applications, noUBBCONFIG
file is provided. You must create aUBBCONFIG
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. - The Oracle Tuxedo software provides three sample
UBBCONFIG
files—ubbshm
,ubbmp
, andubbsimple
—as part of thebankapp
andsimpapp
applications. (See Tutorials for Developing Oracle Tuxedo ATMI Applications.) - The
TUXCONFIG
file is a binary version of the configuration file, created from the text version by the tmloadcf(1) command. Beforetmloadcf
is executed, the environment variableTUXCONFIG
must be set to the full pathname of the device or system file whereTUXCONFIG
is to be loaded. If necessary, many parameters inTUXCONFIG
can be changed while the application is running by using tmconfig, wtmconfig (1) or the MIB.
See Also:
- UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference
- tmconfig, wtmconfig (1), and tmloadcf(1) in the Section 1 - Commands
Parent topic: What Is the Configuration File?
2.2 Contents of the Configuration File
The following table lists the nine sections of the configuration file and describes the purpose of each section.
Table 2-1 Contents of the Configuration File
Section | Required or Optional | Purpose |
---|---|---|
RESOURCES | Required | Defines all system parameters. |
MACHINES | Required | Specifies all the machines in your application. |
GROUPS | Required | Defines all groups, group names, and group IDs for your application. |
SERVERS | Optional | Specifies the initial conditions for servers started in the system. |
SERVICES | Optional | Provides information on services used by the application. |
INTERFACES | Optional | For CORBA environments, provides information on application-wide, default parameters for interfaces used by the application. |
NETWORK | Optional | Describes the network configuration for a LAN environment. |
NETGROUPS | Optional | Describes the network groups available to the application in the LAN environment. |
ROUTING | Optional | 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 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.
- A single-machine application—one or more local or remote clients communicate with one or more servers residing on the same machine.
- A multiple-machine (distributed) application—one or more local or remote clients communicate with one or more servers residing on several machines.
- A multiple-domain application—two or more applications communicate with each other through the use of the Oracle Tuxedo Domains extension. Each application included in such a configuration is called a domain.
Parent topic: About the Configuration File
2.3 CORBA Administrative Requirements and Performance
This section provides information to assist you in administering your CORBA environment in the Oracle Tuxedo system.
Parent topic: About the Configuration File
2.3.1 Configuring NameManager
Adhering to the following requirements is fundamental to successful CORBA administration.
- NameManagers coordinates their activities with each other using the Oracle Tuxedo EventBroker without administrative or operations intervention. The EventBroker is started before any servers provide the NameManager service. If the EventBroker is not configured into the application and is not running when the NameManager service is booted, the NameManager aborts its startup and writes an error message to the user log.
- At least two servers must be configured to run the NameManager service as part of any application. This requirement is to ensure that a working copy of the “name-to-IOR” mapping is always available. If the servers are on different machines, and one machine crashes, when the machine and application are restarted, the new NameManager obtains the mapping from the other NameManager. If an application is solely contained on one machine and the machine crashes, the NameManagers are rebooted as part of the application startup because the application must be rebooted. If two NameManagers are not configured in the application when a NameManager service is booted, the NameManager aborts its startup and writes an error message to the user log.
- NameManagers can be designated as either master or slave, the default being slave. If a master NameManager server is not configured in the application and is not running when a slave NameManager server starts, the server terminates itself during boot and writes an error message to the user log.
- If a NameManager service is not configured in the application
when a FactoryFinder service is booted, the FactoryFinder aborts
its startup and writes an error message to the user log. It is not
necessary for the NameManager service to start before a
FactoryFinder service because the FactoryFinder only communicates
with a NameManager when a
“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. - Oracle Tuxedo EventBroker, NameManager, and FactoryFinder services must be started before any of the application-specific servers. However, if more than one EventBroker is to be configured in the application, all secondary EventBrokers must be started after all application servers are started. There is no system protocol to enforce this in an application server; therefore, you accomplish this by positioning all secondary EventBrokers after the application servers.
- The Master NameManager is started and must be running before any application server can register a reference to a factory object. The existence of an executing Slave NameManager is not sufficient.
Parent topic: CORBA Administrative Requirements and Performance
2.3.2 Reliability Requirements
This section contains information to improve CORBA reliability.
- Managing Factory Entries
- Configuring Multiple NameManagers and FactoryFinders
- Designating a Master NameManager
Parent topic: CORBA Administrative Requirements and Performance
2.3.2.1 Managing Factory Entries
When application servers stops functioning, 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.
Parent topic: Reliability Requirements
2.3.2.2 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.
Parent topic: Reliability Requirements
2.3.2.3 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.
Parent topic: Reliability Requirements
2.3.3 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:
- How to Create a Configuration File
- How to Create the Configuration File for a Multiple-machine (Distributed) Application
- “Oracle Tuxedo Domains (Multiple-Domain) Servers” in Introducing Oracle Tuxedo ATMI
- “How to Create the TUXCONFIG File” in Administering a Oracle Tuxedo Application at Run Time
- For distributed Oracle Tuxedo CORBA applications, refer to the Scaling, Distributing, and Tuning CORBA Applications guide.
Parent topic: CORBA Administrative Requirements and Performance