Figure 4‑1 shows the relationship between administrative commands and servers in the Domains administrative subsystem.
•
|
dmadmin(1) command, a generic administrative service—Enables administrators to configure, monitor, and tune domain gateway groups dynamically, and to update the Domains configuration file ( BDMCONFIG) while the Oracle Tuxedo application is running. The command acts as a front-end process that translates administrative commands and sends service requests to the DMADMIN service, a generic administrative service advertised by the DMADM server. The DMADMIN service invokes the validation, retrieval, or update of functions provided in the DMADM server to maintain the BDMCONFIG file.
|
•
|
DMADM(5), the Domains administrative server—Provides the administrative processing required for updating the Domains configuration. This server acts as a back-end to the dmadmin command. It provides a registration service to domain gateway groups. This registration service is requested by GWADM servers as part of their initialization procedure. The registration service downloads the configuration information required by the requesting domain gateway group. The DMADM server maintains a list of registered domain gateway groups, and propagates to these groups any changes made to the configuration.
|
•
|
GWADM(5), the gateway administrative server—Registers with the DMADM server to obtain the configuration information used by the corresponding domain gateway group. The GWADM accepts queries from DMADM to obtain run-time statistics or to change the run-time options of the corresponding domain gateway group. Periodically, the GWADM server sends an “I-am-alive” message to the DMADM server. If no reply is received from the DMADM server, the GWADM server registers again. This mechanism makes sure the GWADM server always has the latest copy of the Domains configuration for its group.
|
•
|
GWTDOMAIN(5), the TDomain gateway server—Provides interoperability between two or more Oracle Tuxedo domains. Working with the WebLogic Tuxedo Connector (WTC) gateway, an Oracle WebLogic Server component, the Oracle Tuxedo TDomain gateway can also provide interoperability between Tuxedo domains and WebLogic Server applications.
|
•
|
BDMCONFIG—the binary version of the Domains configuration file, which together with the TUXCONFIG file and factory_finder.ini file (CORBA only) contain all the configuration parameters that the Oracle Tuxedo software needs to create a Domains configuration.
|
dmadmin is an administrative interface to the
DMADM and
GWADM servers. The communication between the two servers is done via FML typed buffers. Administrators can use the
dmadmin command in the following ways:
The DMADM server advertises two services:
•
|
DMADMIN, which is used by the dmadmin command and the GWADM server.
|
•
|
A service called DMADM_svrid, where srvid is the appropriate server ID for the service. Registered GWADM servers use DMADM_svrid for specific administrative functions (for example, to refresh the domain gateway group configuration information or to signal that a GWADM is still registered).
|
The DMADM server must be defined in the
SERVERS section of the
TUXCONFIG file as a server running within a group (for example,
DMADMGRP). There should be only one instance of the
DMADM server in this group.
•
|
DMADM(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
•
|
Getting Domains configuration information from the DMADM server, and accepting queries from dmadmin. The GWADM server gets the domain gateway group configuration information by registering with the DMADM server. The GWADM server then makes the configuration available to gateways by storing the information in shared memory.
|
•
|
Providing transaction logging functionality for a domain gateway group. The GWADM server determines which transactions need to be logged by reading information stored in shared memory. When the GWADM server is booted, it scans the log to see whether any transactions need to be recovered, and then reconstructs the transaction information in shared memory. The gateway server scans the information in shared memory and performs recovery for the corresponding transactions. The recovery procedure is performed asynchronously with new incoming or outgoing requests received by the domain gateway group.
|
The GWADM server advertises a service name based on the local domain access point name (as specified in the
DM_LOCAL section of the
BDMCONFIG file) associated with the domain gateway group to which the
GWADM server belongs. The
dmadmin command uses this service to retrieve information from all active domain gateway groups or from a specific domain gateway group.
The GWADM server must be defined in the
SERVERS section of the
TUXCONFIG file. It should not be part of the
MSSQ used by the gateways associated with the group. It must be the first server booted within the domain gateway group; that is, either (a) it must have a
SEQUENCE number, or (b) it must be defined ahead of the gateway servers.
The GWADM server requires the existence of a
DMADM server. Specifically, a
DMADM server must be booted before that
GWADM is booted.
The GWADM server must create the shared memory required by the domain gateway group to populate the configuration tables with information received from the
DMADM server. The
GWADM server uses
IPC_PRIVATE with
shmget and stores the
ipckey returned in the
shmid field of its registry entry in the bulletin board. Gateways can obtain the
ipckey by retrieving the
GWADM registry entry and checking the
shmid field.
•
|
GWADM(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference
|
The Oracle Tuxedo system architecture uses a separate process, the Transaction Manager Server (TMS), to coordinate the commitment and recovery of transaction branches accessing a particular group. In a Domains environment, however, this architecture would require extra messages from the gateway to the
TMS server to process a commitment for an incoming transaction. To simplify the Domains architecture and to reduce the number of messages, the
TMS code is integrated with the gateway code. Thus, domain gateways can process the transaction protocol used by the Oracle Tuxedo system. The Oracle Tuxedo transaction protocol requires that the domain gateway group advertise the
TMS service, which is done when the first gateway is booted. Once the
TMS service is advertised, any transaction control messages directed to the domain gateway group are placed on the gateway’s queue.
Domain gateway groups should be defined in the TUXCONFIG file without the
TMSNAME,
TMSCOUNT,
OPENINFO, and
CLOSEINFO parameters. These four parameters apply only to groups that use an XA-compliant resource manager, which domain gateways do not use.
In the Oracle Tuxedo system, the TMS is a special server that is implicitly associated with server groups that use X/Open XA-compliant resource managers. The
TMS server releases application servers from the delays associated with the distributed 2-phase commitment protocol.
TMS servers coordinate the commitment of a transaction via special service requests to the
TMS service, which is offered by all
TMS servers.
In a Domains environment, GWTDOMAIN gateways are not associated with an XA-compliant resource manager. The Transaction Processing Working Group (
TPWG) of X/Open has proposed an advanced XA interface. This interface is not used in the Oracle Tuxedo system because the interface does not match the highly asynchronous and non-blocking model required by the gateway. While domain gateways do not use a separate
TMS server, they do offer the Transaction Manager Servers capability, which allows gateways to coordinate the 2-phase commitment of transactions executed across domains.
1.
|
Domain gateways advertise the TMS service and perform all operations associated with that service. Messages sent to this service are placed on the queue used by the appropriate domain gateway group, and the gateways manage the transactions associated with the group.
|
A GTRID is a
Global
Transaction
Identifier.
GTRID mapping defines how to construct a transaction tree that crosses domain boundaries. You specify
GTRIDs using the
MAXGTT parameter in the
RESOURCES section of the Oracle Tuxedo configuration file.
A tightly-coupled relationship is one in which a single transaction identifier,
XID, is used by all processes participating in a single global transaction, accessing a single RM. This relationship maximizes data sharing between processes; XA-compliant RMs expect to share locks for resources used by processes having the same
XID. The Oracle Tuxedo system achieves the tightly-coupled relationship via the group concept; that is, all work done by a group on behalf of a given global transaction belongs to the same transaction branch; all the processes executed by the group are given the same
XID.
In a loosely-coupled relationship, the
TMS generates a transaction branch for each part of the work in support of the global transaction. The RM handles each transaction branch separately; there is no sharing of data or of locks between the transaction branches. Deadlocks between transaction branches can occur and result in the rollback of a global transaction. In the Oracle Tuxedo application, when different groups participate in a single global transaction, each group defines a separate transaction branch, which results in a loosely-coupled relationship.
The TDomain instantiation tries to optimize GTRID mapping by implementing a tightly-coupled relationship. In TDomain, multiple service requests issued on behalf of the same global transaction are mapped to the same network transaction branch. Therefore, incoming service requests can be mapped to a single Oracle Tuxedo transaction. However, the hierarchical structure of interdomain communication and the interdomain transaction tree must still be maintained.
Figure 4‑4 shows the service request graph for a client that generates three service requests: one local request (
r0) and two remote requests (
r2 and
r3). Request
r0 goes to a local service (
Svc0), which generates another remote service request (
r1). Request
r1 goes to remote service
Rsvc1, which issues a loopback service request
r4 to local service
Svc4.
Svc0 and
Svc4 are executed in different groups (
G0 and
G4). The domain gateway is executed within another group (
GW), and the remote services
Rscv1,
Rsvc2, and
Rsvc3 are executed in another domain (Domain B).
Finally, there is the loopback service request r4 that generates another branch in the transaction tree. OSI TP maps this request to identifier
T2, but XAP-TP generates a new branch in its transaction tree (
r4: B to A'). This is a new transaction branch on Domain A, and therefore, the gateway generates a new mapping
T5 to a new Oracle Tuxedo transaction. Therefore, the transaction graph shows that domain gateway group GW on Domain A coordinates group
G4.
When a TMS is the superior of a domain gateway group, the Oracle Tuxedo
TLOG is still required to coordinate the commitment.
Logging is performed by the GWADM administrative server. The request for a log write is made by the
GWTDOMAIN process, but the actual log write is performed by the
GWADM process.
You must create a log called DMTLOG for each domain gateway group. The
DMTLOG files are defined in the
DM_LOCAL section of the
DMCONFIG file. To create a
DMTLOG file, add an entry for the
DMTLOGDEV parameter:
where string is the name of the log file. In addition, you cam set one or both of the two optional parameters:
If a DMTLOG has not been created when a domain gateway group is booted, the gateway server automatically creates the log, based on information in the
BDMCONFIG file.
•
|
Ready record—a ready record is a file created by a gateway acting as a leaf or intermediate machine in a transaction tree. It records information about the superior and subordinate remote domains involved in the transaction. A ready record indicates that all subordinates of the domain gateway group logging the record have been prepared.
|
•
|
Commit record—a commit record documents that a transaction has been committed. A domain gateway creates a commit record as the coordinator of a particular transaction tree.
|
•
|
Log Heuristic record—this record holds the details of a heuristic decision in the domain until the outcome of the relevant transaction is known by the superior.
|
•
|
Log Damage record—this record is created to indicate one of two conditions for a transaction branch: (run with tmadmin(1)) a heuristic hazard (when the outcome of the transaction branch for a subordinate is unknown) or a heuristic mix (when the transaction subtree has a mixed outcome).
|
In OSI TP, any blobs stored in the
DMTLOG with a transaction record are passed to the network access module, which uses the blobs to reconstruct its internal state and to recover any failed connections