Configuring Distributed Transaction Processing

Distributed Transaction Processing (DTP) is a major capability of TUXEDO System. This chapter

Planning for Distributed Transaction Processing

DTP implies the coordination of autonomous actions as a single logical unit of work. By "autonomous actions" we mean actions that involve multiple server groups and/or multiple resource manager interfaces. The "unit of work" is called a global transaction.

DTP almost always is implemented on a network of processors defined in the *NETWORK section of the configuration file. It frequently uses data dependent routing, the mechanics of which are defined in the *ROUTING section. A critical part of DTP, however, is the arrangement between server groups, processors, transaction manager servers and resource managers.

Note: This chapter deals with specifying resource manager instances. In all discussions of this topic we use TUXEDO/D and TUXEDO/SQL for examples. These are products that are distributed with the TUXEDO System only as part of the sample application, bankapp.

For the purposes of our discussion here we assume that all planning of the network has been done and the *NETWORK section of the configuration file has been specified. (See Chapter 4, BEA TUXEDO System Networks".)

Data dependent routing is a separate consideration; while it may be a feature of a DTP application, you can have DTP without having data dependent routing. Therefore we are leaving it out of this discussion. (See Chapter 6, "Buffer Types".)

Most of the definition of DTP is done in the *GROUPS and *MACHINES sections, with some associated parameters in the *RESOURCES section. In *GROUPS you associate a group of servers with a specific instance of a resource manager. We use the term "instance" here to mean the combination of

In addition, you specify a particular type of transaction manager server (TMS) that is written to coordinate distributed transactions originating in the group. Finally, you pin all this to one particular processor (with maybe an alternate, if you plan to enable migration).

Configuration Parameters that Implement DTP

In this part of the chapter we take a look at the parameters in *RESOURCES, *MACHINES and *GROUPS that apply to distributed transaction processing.

*RESOURCES Section Parameters

The following parameters need to be considered to implement DTP successfully. It is probably reasonable to accept the defaults to begin with. When your application is running you will be able to gather information that might lead you to change to different values.

MAXGTT

MAXGTT controls the number of entries allowed in the global transaction table of a bulletin board. Entries remain in the table only while the global transaction is active, so this parameter has the effect of setting a limit on the number of simultaneous transactions. The upper limit for MAXGTT is 2048; the default is 100 transactions. Picking a value is entirely application-dependent; the only penalty for over-estimating is that it increases the size of your bulletin board perhaps unnecessarily.

MAXGTT can also be specified in the *MACHINES section. If specified there it will override the value in the *RESOURCES section for the given machine.

CMTRET

CMTRET provides a means of controlling (in a small way) when a commit is considered complete and control returned to the process that called tpcommit(3c). The two possible values are LOGGED and COMPLETE. The default is COMPLETE, which means that control is not returned to the calling process until the two-phased commit is entirely finished. If you specify LOGGED, control is returned when all participants have been logged as ready to commit. You may sometime fall victim to a network failure that occurs between the moment of logging and the moment the second phase of the commit is complete. Many applications decide they can live with that degree of risk for the sake of slightly speeded up processing. The decision really depends on the importance to the application of absolute accuracy of data. This parameter provides an initial setting for the TP_COMMIT_CONTROL characteristic for processes joining the application. tpscmt(3c) can be used to reset this characteristic.

SCANUNIT

SCANUNIT sets the time interval (in seconds) between scans by the BBL for timed-out transactions and blocking calls within service requests. The value for this parameter has to be divisible by 5 and can not be greater than 60. This is the basic unit; it is combined with a multiplier in SANITYSCAN, DBBLWAIT, BBLQUERY and BLOCKTIME to set other time limits. The default value for SCANUNIT is 10 (seconds). Leave these parameters at their default values until you have some history to go on.

*MACHINES Section Parameters

The *MACHINES section parameters most closely connected with DTP are those that define the transaction log. The transaction log parameters are all keyword/value pairs specified for each entry in the section, or specified on a DEFAULT: line to apply to several entries.

TLOGDEVICE

The value of this parameter specifies the device in the TUXEDO System file system that contains the transaction log. This can be the same device used by TUXCONFIG.

Note: Technically, there is no reason why TLOGDEVICE can not be a separate VTOC file, but there are these things to be said against that strategy: 1) the TLOG is generally too small to warrant devoting a raw disk segment to it, 2) creating it as a UNIX file runs into expensive delays when synchronous writes to the TLOG are required.

The TLOG is stored as a TUXEDO System VTOC table on the device named in this parameter. If the TLOGDEVICE parameter is not specified, there is no default; System/T assumes that no TLOG exists for the machine. If no TLOG exists for a given machine, it means that the associated LMID can not be used by server groups that participate in distributed transactions.

After TUXCONFIG has been created via tmloadcf, you must create a device list entry for the TLOG on each machine for which TLOGDEVICE is specified. This is done using the tmadmin crdl command. The BBL creates the log automatically the first time the system is booted.

TLOGNAME

TLOGNAME specifies the name of the DTP transaction log for this machine. The default name is TLOG. If more than one transaction log exists on the same TLOGDEVICE, they must have unique names. If a name is specified, it must not conflict with any other table specified on the configuration.

TLOGOFFSET

TLOGOFFSET specifies the offset in pages from the beginning of TLOGDEVICE to the start of the VTOC that contains the transaction log for this machine. The number must be greater than or equal to 0 and less than the number of pages on the device. The default value is 0.

TLOGOFFSET is rarely necessary. If two VTOCs share the same device or if a VTOC is stored on a device (such as a file system) that is shared with another application, TLOGOFFSET can be used to indicate a starting address relative to the address of the device.

TLOGSIZE

TLOGSIZE specifies the number of pages for the TLOG. The default is 100 pages. After a global transaction is completed the TLOG records are no longer needed and are thrown away. The maximum that can be specified, subject to the amount of available space on TLOGDEVICE, is 2048 pages. Picking a value is entirely application-dependent. The best setting for TLOGSIZE is MAXGTT.

*GROUPS Section Parameters

The *GROUPS section must follow *RESOURCES and *MACHINES in the UBBCONFIG file, and must have at least one entry.

Parameters in the *GROUPS section implement two important aspects of distributed transaction processing. They associate a group of servers with a particular LMID and a particular instance of a resource manager. In addition, by allowing a second LMID to be associated with the server group, they name an alternate processor to which a group of servers can be migrated if the MIGRATE option is specified. The format for entries in this section is:

GRPNAME [parameters]
so, in this section we are giving a name to a group of servers and associating with it several parameters that apply to that group. The name must be unique within all group names in the section and cannot duplicate any LMID name assigned in the *MACHINES section.

LMID

LMID must be one of the entries assigned in the *MACHINES section. It says that this server group will run on this particular processor. A second LMID value can be specified (separated from the first by a comma) to name an alternate processor to which this server group can be migrated if the MIGRATE option has been specified. Servers in the group must specify RESTART=Y in order to migrate. (See the discussion of the migrate commands in the chapter on tmadmin.)

GRPNO

GRPNO is a required parameter that associates a numeric group number with this server group. The number must be greater than 0 and less than 30000. It must be unique among entries in the *GROUPS section in this configuration file.

TMSNAME

The TMSNAME parameter is used to specify which transaction management server (TMS) should be associated with this server group. One TMS is provided with TUXEDO System; two others are provided with TUXEDO System/D. These are as follows:

TMS
used with servers that participate in a global transaction but that do not have an XA-compliant resource manager.

TMS_D
TMS_D should be specified when TUXEDO/D is the resource manager associated with this group of servers.

TMS_SQL
TMS_SQL should be specified when TUXEDO/SQL is the resource manager associated with this group of servers.

If you are integrating another resource manager with System/T, the name you specify here is the name of the output file created with buildtms(1).

TMSCOUNT

This is an optional parameter that can be used to specify how many copies of TMSNAME should be started for this server group. The minimum value is 2. If not specified, the default is 3. All TMSNAME servers started for a server group are automatically set up in an MSSQ set.

OPENINFO

The OPENINFO parameter specifies information needed to open a particular instance of a particular resource manager, or it says that such information is not required for this server group (there's more on this below). When a resource manager is named in the OPENINFO parameter, information such as the name of the database and the access mode is included. The entire value string must be enclosed in double quotes and must not be more than 256 characters.

The format of the OPENINFO string is dependent on the requirements of the vendor providing the underlying resource manager. The string required by the vendor must be prefixed with rm_name:, which is the published name of the vendor's transaction (XA) interface followed immediately by a colon (:).

For TUXEDO System databases, the format is:


OPENINFO="TUXEDO/D:fsconfig:dbname:openmode"
where "TUXEDO/D" is the published name of the TUXEDO System XA interface, fsconfig is the name of the FSCONFIG on which the database resides, dbname is the name of the database, and openmode is one of readonly or readwrite. For NT and NetWare, the colon separator after fsconfig and dbname must be a semi-colon.

For TUXEDO System/SQL databases, the format is:


OPENINFO="TUXEDO/SQL:fsconfig:dbname:openmode"
where "TUXEDO/SQL" is the published name of the TUXEDO System/SQL XA interface, fsconfig is the name of the FSCONFIG on which the database resides, dbname is the name of the database, and openmode is one of readonly or readwrite. For NT and NetWare, the colon separator after fsconfig and dbname must be a semi-colon.

The OPENINFO parameter is ignored if TMSNAME is not set or is set to TMS. If TMSNAME is set but the OPENINFO string is set to the null string ("") or this parameter does not appear on the entry, it means that a resource manager exists for the group but does not require any information for executing an open operation.

For server group migration to work, the pathname specified for fsconfig must be the same on both processors identified by the two LMIDs for the server group.

CLOSEINFO

The CLOSEINFO parameter is used to specify information the resource manager needs when closing a database. In the case of the two TUXEDO System interfaces, TUXEDO/D and TUXEDO/SQL, no information is needed. The parameter can either be omitted or the null string can be specified. The default is the null string.

*SERVICES Section Parameters

The *SERVICES section contains parameters that control the way application services are handled. An entry line in this section is associated with a service by its identifier name. Since the same service can be link edited with more than one server, the SRVGRP parameter is provided to tie the parameters for an instance of a service to a particular group of servers.

The format for entries in the section is

SVCNM [parameters]
There are three parameters in the *SERVICES section that are particularly related to DTP.

ROUTING

The ROUTING parameter in *SERVICES points to an entry in the *ROUTING section where data dependent routing is specified for transactions that request this service.

AUTOTRAN

The AUTOTRAN parameter can be set to a value of Y or N meaning that a transaction should be (or not be) automatically started if a message received by this service is not already in transaction mode. The default is N. Use of the parameter should be coordinated with the programmers coding the services for your application. They are in a better position to determine the proper setting for AUTOTRAN in your application.

TRANTIME

The TRANTIME parameter is used to set a timeout value in seconds for transactions automatically started in this service. The default is 30 seconds. The TRANTIME parameter is only needed if AUTOTRAN = Y, and not even then if the default is acceptable.

Example

The DTP-related parameters for the sample application can be found in Figure 1 sample application.

Figure 1: DTP-related parameters for bankapp, MP model

*RESOURCES
MAXGTT		20
SCANUNIT		10
#
*MACHINES
		# Substitute values appropriate for your application
		# for items enclosed in angle brackets <>
DEFAULT:	TLOGNAME=TLOG
<SITE1's uname> LMID=SITE1
		TLOGDEVICE="<APPDIR>/TLOG"
<SITE2's uname>	LMID=SITE2
		TLOGDEVICE="<APPDIR>/TLOG"
#
*GROUPS
DEFAULT:	TMSNAME=TMS_SQL	TMSCOUNT=2
# For NT/NetWare, :bankdb: becomes ;bankdb;
BANKB1		LMID=SITE1	GRPNO=1
	OPENINFO="TUXEDO/SQL:<APPDIR>/bankdl1:bankdb:readwrite"
BANKB2		LMID=SITE2	GRPNO=2
	OPENINFO="TUXEDO/SQL:<APPDIR>/bankdl2:bankdb:readwrite"
#
		# *SERVICES parameters AUTOTRAN and TRANTIME: system default taken