[Top]
[Previous Page] [Next Page] [Bottom]
This chapter discusses the following topics:
Transactions greatly simplify the writing of distributed applications. They allow your application to cope more easily with a large set of problems that occur in a distributed environment, such as machine, program, or network failures. One of the greatest strengths of the BEA TUXEDO system is that the transaction semantic was built into the software and into the TUXEDO ATMI. Global transactions were woven into the fabric of the system and into its communication APIs and protocols.
The ability to define a global transaction around communication calls makes it an indispensable tool for writing distributed applications. A global transaction allows not only the effects of your communications to be committed as a single unit, but it also gives you a simple, programmatic way to undo work if errors occur.
To illustrate the power of global transactions, consider the following example. A Place Order service performs two operations: it updates the Order database and enqueues the order to the shipping department. The business intends that both these actions occur together as a unit or that neither action should occur if one action fails.
To accomplish this, the client application invoking the Place Order service associates the call with a global transaction. You do this by using the ATMI begin-transaction function before issuing the service request, and issuing the commit-transaction function after it. Because the service is invoked as part of a global transaction, its work is done on its behalf. The server is propagated with the client's transaction when the Place Order service is invoked. Both the database access and the enqueue operation to the shipping application queue become part of the client's transaction.
Should either operation fail because of an application or system error, the work done in the transaction is rolled back to its state at the outset of the transaction. If both succeed, however, the client's call to commit the transaction causes the effects of the database update and the enqueued message to become permanent records of this transaction.
You must modify the RESOURCES,
MACHINES, GROUPS, and the SERVICES sections of the
application's UBBCONFIG
file in the following way to accommodate transactions:
RESOURCES
section, specify the application-wide number of allowed transactions, and the value of the
commit control flag. MACHINES
section, create the TLOG
information for each machine. GROUPS section,
indicate information about each resource manager, and about the transaction manager
server. SERVICES
section, enable the automatic transaction option. The following table provides a description of transaction-related parameters in the RESOURCES section of the
configuration file.
This section discusses creating a TLOG.
The Universal Device List (UDL) is like a map of the BEA TUXEDO file system. The UDL
gets loaded into shared memory when an application is booted. The TLOG refers to a log in which
information on transactions is kept until the transaction is completed.To create an entry
in the UDL for the TLOG
device, create the 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 the UDL, enter a command using the following format, before the application has been booted:
tmadmin -c crdl -z config
-b blocks
In the preceding format statement, specify in the -z config argument the full
path name for the device where you should create the UDL. Specify in the -b blocks argument the
number of blocks to be allocated on the device. config should match the value
of the TLOGDEVICE
parameter in the MACHINES
section of the UBBCONFIG
file.
Note: In general, the value that you supply for blocks should not be less than the
value for TLOGSIZE. For
example, if TLOGSIZE is
specified as 200 blocks, specifying -b
500 would not cause a degradation.
For more information about storing the TLOG, see the BEA TUXEDO Installation Guide.
You can define a global transaction log (TLOG) using several parameters in the MACHINES section of the UBBCONFIG file. You must manually
create the 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 it
must be done before the system is booted.
The following table provides a description of transaction-related parameters in the MACHINES section of the
configuration file.
You can create the Domains transaction log before starting the Domains gateway group by
using dmadmin(1) crdmlog (crdlog) -d local_domain_name.
Create the Domains transaction log for the named local domain on the current machine (that
is, the machine where dmadmin
is running). 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 the log already exists. If
the transaction log has not been created, the Domains gateway group creates the log when
the Domains gateway group starts.
Additions to the GROUPS
section fall into two categories:
TMSNAME
parameter is the name of the server executable; TMSCOUNT is the number of such servers to boot (minimum 2, maximum
10, default 3).TMS and it simply begins, commits,
or terminates without talking to any RM. OPENINFO is a string with
information used to open a resource manager, and CLOSEINFO is used to close a resource manager. The following is an example from the GROUPS section in the banking application, called bankapp.
BANKB1 GRPNO=1 TMSNAME=TMS_SQL TMSCOUNT=2 OPENINFO="TUXEDO/SQL:<APPDIR>/bankdl1:bankdb:readwrite"
The following table describes the transaction values shown in the sample GROUPS section.
The following table lists the characteristics of the TMSNAME, TMSCOUNT, OPENINFO, and CLOSEINFO parameters.
The following table lists the characteristics of the AUTOTRAN, TRANTIME, and FACTORYROUTING parameters.
The following are three transaction-related additions in the SERVICES section:
AUTOTRAN flag to Y. This is useful if the 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 there is already an
existing transaction, this call becomes part of it. (The default is N.) Note: Generally, clients are the best initiators of transactions because a service has the potential of participating in a larger transaction.
AUTOTRAN is set to Y, you must set the TRANTIME parameter, which is the
transaction timeout in seconds for the transactions to be created. The value must be
greater than or equal to 0
and must not exceed 2,147,483,647 (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 request data-dependent routing. The following table lists the characteristics of the AUTOTRAN, TRANTIME, and ROUTING parameters.
To enable transactions across domains, you need to set parameters in both the DM_LOCAL_DOMAINS and the DM_REMOTE_SERVICES sections of the
Domains configuration file (DMCONFIG).
Entries in the DM_LOCAL_DOMAINS
section define local domain characteristics. Entries in the DM_REMOTE_SERVICES section define
information on services that are imported and that are available on remote
domains.
The DM_LOCAL_DOMAINS
section of the Domains configuration file identifies local domains and their associated
gateway groups. This section must have an entry for each gateway group (Local Domain).
Each entry specifies the parameters required for the Domains gateway processes running in
that group.
The following table provides a description of the five transaction-related parameters
in this section: DMTLOGDEV,
DMTLOGNAME, DMTLOGSIZE, MAXRDTRAN, and MAXTRAN.
The DM_REMOTE_SERVICES
section of the Domains configuration file identifies information on services imported
and available on remote domains. Remote services are associated with a particular remote
domain.
The following table describes the two transaction-related parameters in this section: AUTOTRAN and TRANTIME.
The following configuration file shows bankapp as an application that is distributed over three sites and
that uses transactions. The application includes the following:
ACCOUNT_ID
BRIDGE processes
communicating with the system via the ATMI
interface The file includes seven sections: RESOURCES,
MACHINES, GROUPS, NETWORK, SERVERS, SERVICES, and ROUTING.
The RESOURCES section
shown in
MAXSERVERS, MAXSERVICES, and MAXGTT are less than the defaults.
This makes the Bulletin Board smaller. MASTER is SITE3 and the backup master is SITE1. MODEL is set to MP and OPTIONS is set to LAN, MIGRATE. This allows a networked
configuration with migration. BBLQUERY is set to 180 and SCANUNIT is set to 10. This means that DBBL checks of the remote BBLs are done every 1800 seconds (one half hour). Listing 7-1 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
The MACHINES section
shown in
TLOGDEVICE and TLOGNAME are specified, which
indicate that transactions will be done. TYPE parameters
are all different, which indicates that encode/decode will be done on all messages sent
between machines. Listing 7-2 Sample MACHINES Section
MACHINES
Gisela 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"
The GROUPS and NETWORK sections shown in
TMSCOUNT is set to
2, which means that only
two TMS_SQL transaction
manager servers will be booted per group. OPENINFO string
indicates that the application will perform database access. Listing 7-3 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"
The SERVERS, SERVICES, and ROUTING sections shown in
TLR servers have a
-T number
passed to their tpsrvrinit()
functions. ACCOUNT_ID field. AUTOTRAN mode. Listing 7-4 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
""
[Top] [Previous Page] [Next Page] [Bottom]