This topic includes the following sections:
Note: | For information about using transactions in a BEA Tuxedo CORBA environment, refer to Using CORBA Transactions. |
To accommodate transactions, you must modify the RESOURCES
, MACHINES
, GROUPS
, and SERVICES
sections of the application's UBBCONFIG
file in the following ways.
The following table describes the transaction-related parameters in the RESOURCES
section.
To create a TLOG
, complete the following tasks:
The Universal Device List (UDL) is a map of the BEA Tuxedo filesystem. The UDL gets loaded into shared memory when an application is booted. The TLOG
refers to a log in which information about transactions is kept until the transaction is completed. To create an entry in the UDL for the TLOG
device, create a UDL on each machine using global transactions. (If the TLOGDEVICE
is mirrored between two machines, it is unnecessary to do this on the paired machine.) The Bulletin Board Liaison (BBL) then initializes and opens the TLOG
during the boot process.
To create a UDL, enter the following command before the application is booted:
tmadmin -c crdl -z
config
-b
blocks
Note: | The command fails if the device already exists. |
The value of config
must be the full pathname of the device on which you create the UDL. It should match the value of the TLOGDEVICE
parameter in the MACHINES
section of the configuration file. The value of blocks
must be the number of blocks to be allocated on the device.
Note: | If the value of blocks is less than the value of TLOGSIZE , you risk a performance degradation. Therefore, you should specify a value for blocks that is greater than that of TLOGSIZE . For example, if TLOGSIZE is specified as 200 blocks, specifying -b 500 does not cause a degradation. |
For more information about storing the TLOG
, see Installing the BEA Tuxedo System.
To define a global transaction log (TLOG
), you must set several parameters in the MACHINES
section of the UBBCONFIG
file.
For one of these parameters, TLOGDEVICE
, you must manually create a device list entry for the TLOGDEVICE
on each machine where a TLOG
is needed. You can do this either before or after TUXCONFIG
has been loaded, but you must complete this step before the system is booted.
The following table describes the transaction-related parameters in the MACHINES
section.
The size, in physical pages, of the
TLOG file. The value must be between 1 and 2048 ; the default, 100 . Assign a value that is large enough to hold the number of outstanding transactions on the machine at a given time. One transaction is logged per page. The default should be enough for most applications.
|
|
Before starting a Domains gateway group, you must create a Domains transaction log. Specifically, you must create a Domains transaction log for the named local domain on the current machine (that is, the machine on which DMADM
is running). To create a log, enter the following command:
dmadmin
crdmlog
crdlog
-d
local_domain_name
The command uses the parameters specified in the DMCONFIG
file. This command fails if the named local domain is active on the current machine or if a log already exists. If a transaction log has not been created, the Domains gateway group creates one when that group starts.
The parameters available for GROUPS
section entries allow you to define the attributes of transaction manager servers (TMSs) and resource managers (RMs) for a particular group.
TMSNAME
contains the name of the executable for the transaction manager server associated with the group defined in the entry. The BEA Tuxedo system provides a null transaction manager server called TMS, which is used by groups that participate in transactions, but do not use an RM. This TMS server does not communicate with any resource manager; it simply manages transactions without communicating with an RM.TMSCOUNT
contains the number of TMSs to be booted (minimum of 2, maximum of 10, default of 3).OPENINFO
and CLOSEINFO
parameters. The value of each is a string that contains information needed to open or close a resource manager, respectively. Appropriate values for these parameters are supplied by RM vendors. For example, if you are using an Oracle database as your RM, you might supply the value shown in the following entry:OPENINFO="ORACLE_XA:
Oracle_XA+Acc=P/Scott/*****+SesTm=30+LogDit=/tmp"
The following sample entry is from the GROUPS
section in bankapp
, the sample banking application you received with the BEA Tuxedo system.
BANKB1 GRPNO=1 TMSNAME=TMS_SQL TMSCOUNT=2
OPENINFO="TUXEDO/SQL:APPDIR
/bankdl1:bankdb:readwrite"
This table describes the transaction values shown in the sample GROUPS entry.
The following table lists the characteristics of the TMSNAME, TMSCOUNT, OPENINFO, and CLOSEINFO parameters.
In certain situations, you may want to set three transaction-related parameters—AUTOTRAN
, TRANTIME
, and ROUTING
—in the SERVICES
section.
AUTOTRAN
flag to Y
. This setting is useful if a service is not needed as part of any larger transaction, and if the application wants to relieve the client of making transaction decisions. If the service is called when a transaction already exists, this call becomes part of it. (The default is N
.)Note: | Generally, clients are the best initiators of transactions because a service can participate in a larger transaction. |
AUTOTRAN
is set to Y
, you must set the TRANTIME
parameter, which is the length of the timeout for transactions to be created. The value must be greater than or equal to 0
, and must not exceed 2,147,483,647
(that is, 231 - 1, or about 70 years). A value of zero implies there is no timeout for the transaction. (The default is 30
seconds.)ROUTING
parameter for transactions that use data-dependent routing.
The following table lists the characteristics of the AUTOTRAN
, TRANTIME
, and ROUTING
parameters.
To work properly, may be dependent on personal communication between the application designer and the application administrator. If the administrator sets this value to Y without prior knowledge of the ICF parameters set by the developer, the wrong application behavior, or failure of the application might be observed.
|
|
To enable transactions across domains, you need to set parameters in both the DM_LOCAL
and the DM_IMPORT
sections of the Domains configuration file (DMCONFIG
). Entries in the DM_LOCAL
section define local domain characteristics. Entries in the DM_IMPORT
section define services that are imported, or available from remote domains.
The DM_LOCAL
section of the Domains configuration file identifies local domains and the gateway groups associated with them. For each gateway group (Local Domain), you must create an entry that specifies the parameters required for the Domains gateway processes running in that group.
The following table describes the five transaction-related parameters in this section: DMTLOGDEV
, DMTLOGNAME
, DMTLOGSIZE
, MAXRAPTRAN
, and MAXTRAN
.
The BEA Tuxedo filesystem that contains the Domains transaction log (
DMTLOG ) for this machine. The DMTLOG is stored as a BEA Tuxedo VTOC table on the TLOGDEVICE (a BEA Tuxedo filesystem). If this parameter is not specified, the Domains gateway group is not allowed to process requests in transaction mode. Local domains running on the same machine can share the same DMTLOGDEV filesystem, but a separate log (a table in the DMTLOGDEV ) must be created for each local domain. The name of each log is determined by the DMTLOGNAME parameter.
|
|||
The name of the Domains transaction log for this domain. If this domain resides on the same filesystem as other local domains (as reflected by a common value for
DMTLOGDEV ), then the value of DMTLOGNAME must be unique for each log. The value may contain a maximum of 30 characters. The default is DMTLOG .
|
|||
The size, in pages, of the Domains transaction log for this machine. The value must be greater than zero and less than the amount of available space on the BEA Tuxedo filesystem. The default is 100 pages.
|
|||
The DM_IMPORT
section of the Domains configuration file provides information about services that are imported and thus available from remote domains. Each remote service is associated with a particular remote domain.
You have the option of setting two parameters in the DM_IMPORT
section that support transactions: AUTOTRAN
and TRANTIME
. The following table describes these parameters.
An additional transaction-timeout property named MAXTRANTIME
from the RESOURCES
section of the UBBCONFIG
file is also available. If the MAXTRANTIME
timeout value is less than the TRANTIME
timeout value or the timeout value passed in a tpbegin(3c)
call to start a transaction, the timeout for a transaction is reduced to the MAXTRANTIME
value. MAXTRANTIME
has no effect on a transaction started on a machine running BEA Tuxedo 8.0 or earlier, except that when a machine running BEA Tuxedo 8.1 or later is infected by the transaction, the transaction timeout value is capped—reduced if necessary—to the MAXTRANTIME
value configured for that node.
For a Domains configuration, the following transaction-handling scenarios are possible:
MAXTRANTIME
parameter, or the node understands the MAXTRANTIME
parameter but the parameter is not set, the timeout value for the transaction is determined by TRANTIME
or by the timeout value passed in the tpbegin()
call that started the transaction. If the TRANTIME
or tpbegin()
timeout value is exceeded, all BEA Tuxedo nodes infected with the transaction—including the node that started the transaction—generate a TMS timeout message.MAXTRANTIME
parameter and the parameter is set for that node, the timeout value for the transaction is reduced to no greater than the MAXTRANTIME
value on that node.
If the TRANTIME
or tpbegin()
timeout value is less than or equal to MAXTRANTIME
, the transaction-handling scenario becomes the one previously described.
If the TRANTIME
or tpbegin()
timeout value is greater than MAXTRANTIME
, the infected node reduces the timeout value for the transaction to MAXTRANTIME
. If the MAXTRANTIME
timeout value is exceeded, the infected node generates a TMS timeout message.
For more information about MAXTRANTIME
, see MAXTRANTIME
in the RESOURCES
section in UBBCONFIG(5)
or TA_MAXTRANTIME
in the T_DOMAIN
class in TM_MIB(5)
.
This section provides sample entries from a configuration file that defines bankapp as an application that supports transactions and is distributed over three sites. The application is characterized by the following:
The file includes seven sections: RESOURCES
, MACHINES
, GROUPS
, NETWORK
, SERVERS
, SERVICES
, and ROUTING
.
The following listing shows a sample RESOURCES
section.
*RESOURCES
#
IPCKEY 99999
UID 1
GID 0
PERM 0660
MAXACCESSERS 25
MAXSERVERS 25
MAXSERVICES 40
MAXGTT 20
MASTER SITE3, SITE1
SCANUNIT 10
SANITYSCAN 12
BBLQUERY 180
BLOCKTIME 30
DBBLWAIT 6
OPTIONS LAN, MIGRATE
MODEL MP
LDBAL Y
In the preceding listing, note the following:
MAXSERVERS
, MAXSERVICES
, and MAXGTT
are set to values that are smaller than the defaults, which reduces the size of the bulletin board.MASTER
is SITE3
and the backup master is SITE1
.MODEL
is set to MP
and OPTIONS
is set to LAN
, MIGRATE
.BBLQUERY
is set to 180
and SCANUNIT
is set to 10
, the DBBL
will check the remote BBL
s every 1800
seconds (that is, every half hour).
The following listing shows a sample MACHINES
section.
*MACHINES
giselle LMID=SITE1
TUXDIR="/usr/tuxedo"
APPDIR="/usr/home"
ENVFILE="/usr/home/ENVFILE"
TLOGDEVICE="/usr/home/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/usr/home/tuxconfig"
TYPE="3B600"
romeo LMID=SITE2
TUXDIR="/usr/tuxedo"
APPDIR="/usr/home"
ENVFILE="/usr/home/ENVFILE"
TLOGDEVICE="/usr/home/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/usr/home/tuxconfig"
TYPE="SEQUENT"
juliet LMID=SITE3
TUXDIR="/usr/tuxedo"
APPDIR='/usr/home"
ENVFILE="/usr/home/ENVFILE"
TLOGDEVICE="/usr/home/TLOG"
TLOGNAME=TLOG
TUXCONFIG="/usr/home/tuxconfig"
TYPE="AMDAHL"
In the preceding listing, note the following:
The following listing shows sample GROUPS
and NETWORK
sections.
*GROUPS
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
BANKB1 LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:/usr/home/bankdl1:bankdb:readwrite"
BANKB2 LMID=SITE2 GRPNO=2
OPENINFO="TUXEDO/SQL:/usr/home/bankdl2:bankdb:readwrite"
BANKB3 LMID=SITE3 GRPNO=3
OPENINFO="TUXEDO/SQL:/usr/home/bankdl3:bankdb:readwrite"
*NETWORK
SITE1 NADDR="0X0002ab117B2D4359"
BRIDGE="/dev/tcp"
NLSADDR="0X0002ab127B2D4359"
SITE2 NADDR="0X0002ab117B2D4360"
BRIDGE="/dev/tcp"
NLSADDR="0X0002ab127B2D4360"
SITE3 NADDR="0X0002ab117B2D4361"
BRIDGE="/dev/tcp"
NLSADDR="0X0002ab127B2D4361"
In the preceding listing, note the following:
The following listing shows sample SERVERS
, SERVICES
, and ROUTING
sections.
*SERVERS
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=N CLOPT="-A"
TLR SRVGRP=BANKB1 SRVID=1 CLOPT="-A -- -T 100"
TLR SRVGRP=BANKB2 SRVID=3 CLOPT="-A -- -T 400"
TLR SRVGRP=BANKB3 SRVID=4 CLOPT="-A -- -T 700"
XFER SRVGRP=BANKB1 SRVID=5 REPLYQ=Y
XFER SRVGRP=BANKB2 SRVID=6 REPLYQ=Y
XFER SRVGRP=BANKB3 SRVID=7 REPLYQ=Y
*SERVICES
DEFAULT: AUTOTRAN=N
WITHDRAW ROUTING=ACCOUNT_ID
DEPOSIT ROUTING=ACCOUNT_ID
TRANSFER ROUTING=ACCOUNT_ID
INQUIRY ROUTING=ACCOUNT_ID
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE="FML"
RANGES="MON - 9999:*,
10000 - 39999:BANKB1
40000 - 69999:BANKB2
70000 - 100000:BANKB3
""
In the preceding listing, note the following: