[Top] [Prev] [Next] [Bottom]

6. Databases for bankapp


Resource Manager Options for bankapp

This chapter covers the subject of the interface between bankapp and a resource manager, typically a database management system. As was mentioned previously, bankapp is written to use the BEA TUXEDO/SQL facilities of the BEA TUXEDO system database, which is an XA-compliant resource manager. The first part of the chapter describes how you create the database for bankapp.

If you do not have BEA TUXEDO/SQL on your system, you have two options:

These two options are discussed in the two later sections of the chapter.

The System/D RM and bankapp

How you create the bankapp database depends on whether you are bringing the application up on a single processor (SHM mode) or on a network of more than one processor (MP mode).

Create Database in SHM Mode

This is a 2-step procedure.

  1. Set the environment by typing the following.

    . ./bankvar

    (If you are bringing up bankapp in one continuous series of steps, you should have done this earlier. bankvar sets a number of parameters that are referenced when bankapp.mk is run.)

  2. Execute crbank. crbank calls crbankdb three times, changing some environment variables each time, so that you end up with three database files on a single machine. That means you can simulate the multi-machine environment of the BEA TUXEDO system without a network of machines.

Create the Database in MP Mode

This procedure is quite similar to the one for SHM mode:

  1. Set the environment by typing the following.

    . ./bankvar

    As noted above, you may already have done this step.

  2. Run crbankdb to create the database for this site.

  3. On each additional machine in your BEA TUXEDO system network, edit bankvar to provide the pathname for the FSCONFIG variable that is used for that site in the configuration file, ubbmp. Then repeat Step 1 and Step 2.

Failure with a semget Error

If crbankdb fails with a semget error, it is saying that it cannot get enough semaphores. Each NPROC requires two semaphores, but you should be able to reduce the number of processes and still run bankapp. Try reducing NPROCTBL=20 in the create database statement in crbankdb.sh to NPROCTBL=10.

Using an XA-compliant RM with bankapp

The procedure for integrating an XA-compliant resource manager with the BEA TUXEDO system is provided elsewhere in the BEA TUXEDO documentation; we will not repeat it here. What is described here are changes that need to be made to bankapp files to enable you to run with an alternate resource manager.

Changes to bankvar

The following environment variables are used in creating the BEA TUXEDO system database.

BLKSIZE=512
DBNAME=bankdb
DBPRIVATE=no
DIPCKEY=80953
FSCONFIG=${APPDIR}/bankdl1

It is unlikely that these correspond to variables needed in creating the database for the alternate resource manager.

Changes to the bankapp Services

Since all database access in bankapp is done with embedded SQL statements, if your new resource manager supports SQL, you should have no trouble. Bear in mind that the utility appinit.c includes calls to tpopen() and tpclose(). tpopen() checks the configuration file to learn how to open the application database.

Change to bankapp.mk

You must edit the RM parameter in bankapp.mk to name the new resource manager.

Also, the name of the SQL compiler and its options may be different (for example, not esqlc). The file suffix may not be .ec and the include directory needed to compile the resulting .c file may be different.

Changes to crbank and crbankdb

crbank might well be ignored and not used with your alternate resource manager. Its only function is to re-set variables and run crbankdb three times. crbankdb, on the other hand, requires close attention. In Listing 6-1 we reproduce the beginning of the crbankdb script to point out things that won't work with a different resource manager.

Listing 6-1 An Excerpt from the crbankdb Script
#Copyright (c) BEA Systems, Inc.
#All rights reserved

#
# Create device list
#
dbadmin<<!
echo
crdl
# Replace the following line with your device zero entry
${FSCONFIG} 0 2560
!
#
# Create database files, fields, and secondary indices
#
sql<<!
echo
create database ${DBNAME} with (DEVNAME='${FSCONFIG}',
IPCKEY=${DIPCKEY}, LOGBLOCKING=0, MAXDEV=1,
NBLKTBL=200, NBLOCKS=2048, NBUF=70, NFIELDS=80,
NFILES=20, NFLDNAMES=60, NFREEPART=40, NLCKTBL=200,
NLINKS=80, NPREDS=10, NPROCTBL=20, NSKEYS=20,
NSWAP=50, NTABLES=20, NTRANTBL=20, PERM='0666',
STATISTICS='n'
)
create table BRANCH (
BRANCH_ID integer not null,
BALANCE real,
LAST_ACCT integer,
LAST_TELLER integer,
PHONE char(14),
ADDRESS char(60),
primary key(BRANCH_ID)
) with (
FILETYPE='hash', ICF='PI', FIELDED='FML',
BLOCKLEN=${BLKSIZE}, DBLKS=8, OVBLKS=2
)
!

These first forty or so lines will give you an idea of what needs to be changed and what may be salvageable. As you can see, crbankdb is made up of two here documents that provide input to the dbadmin and sql shell commands. The first here file is passed to the BEA TUXEDO system command dbadmin to create a device list for the database. Obviously, this will not work with another resource manager. Other commands may be needed to create table spaces and/or grant the correct privileges.

The second here file is passed to System/D's interactive SQL. BEA TUXEDO/SQL conforms closely to the standard SQL, but the with clauses of the create database and create table statements are specific to System/D.

Note: In the scripts furnished with bankapp the create table statement shown in Listing 6-1 is followed by three other create table statements and two create index statements. The remarks here apply to all of these statements.

Changes to the Configuration File

This gets a little ahead of our sequence of chapters (configuration files are discussed in Chapter 7, "Edit bankapp Configuration Files."), but you will have to change the *GROUPS section to specify a different TMSNAME parameter and to provide an OPENINFO parameter that is recognizable by the new resource manager.

Using a non-XA Compliant RM with bankapp

The most significant difference between a resource manager that is not XA-compliant and one that is, is that the non-XA resource manager does not take full advantage of the BEA TUXEDO system Distributed Transaction Processing (DTP) features. Your resource manager will operate as a local resource on the machine on which it resides and clients within a DTP transaction will not be able to request services from your resource manager.

For the discussion at hand, we're going to assume you want to connect an RDBMS that doesn't use the XA 2-phase commit to bankapp. The non-XA resource manager will be the only resource manager used by the application; the problem of integrating XA and non-XA resource managers in bankapp is not covered in this discussion. You expect to be able to access the database using embedded SQL statements such as those delivered with bankapp. The most important change in the functionality of bankapp that results from this is that the TRANSFER service will no longer be a single, atomic transaction. If a system error should occur between the withdrawal and the deposit in TRANSFER, you run the risk of having a corrupted database.

Changes to bankvar

The following variables can be left null in bankvar because they are parameters for the BEA TUXEDO system database.

BLKSIZE
DBNAME
DBPRIVATE
DIPCKEY
FSCONFIG

The following variable can be left null in bankvar because a TLOG is needed only for DTP transactions.

TLOGDEVICE

Changes to the bankapp Clients and Services

In the .m files; that is, the source code for bankapp masks, change the following.

TRANMODE=TRAN

to

TRANMODE=NOTRAN

In audit.c and auditcon.c remove the tpbegin(), tpcommit(), and tpabort() statements.

All calls to tpopen() and tpclose() must be removed. In each service, a local transaction must be started at the beginning of the service and a commit or rollback must be done before each tpreturn(). The service OPEN_ACCT will need to be re-written since it calls the DEPOSIT service, so that the work of DEPOSIT is done within the same transaction in the same server. Similarly, CLOSE_ACCT calls WITHDRAW, and XFER calls DEPOSIT and WITHDRAW. These functions (DEPOSIT, WITHDRAW) should be re-written as non-service functions with normal returns that can be called from different service functions.

Changes to bankapp.mk

In bankapp.mk, set RM to null. Change all buildserver lines to remove the -r flag and to include the libraries needed by your resource manager. A typical buildserver line should look like this.

buildserver -f servicefile.o -o servername -l "rmlibs,..."

The libraries for your resource manager will not be brought in automatically as happens with XA-compliant resource managers that are listed in TUXDIR/udataobj/RM, so you have to specify what libraries you need on the buildserver command line.

Changes to crbank and crbankdb

Do not use crbank.

You may be able to salvage some of the create table statements in crbankdb. At any rate, you should plan to use the same table and field names in your database as are used in bankapp in order to be able to use the existing services.

Changes to the Configuration File

In the *GROUPS section, change the existing entries as follows.

If you are using ubbshm.

*GROUPS
DEFAULT: LMID=SITE1
BANKB1 GRPNO=1
BANKB2 GRPNO=2
BANKB3 GRPNO=3

If you are using ubbmp.

*GROUPS
DEFAULT:
BANKB1 LMID=SITE1 GRPNO=1
BANKB2 LMID=SITE2 GRPNO=2

The above changes do two things: you remove the TMSNAME specification so you default to the null XA interface, and you remove the OPENINFO statements, which are not used with the null XA interface.

In addition to these changes, change the DEFAULT entry for the *SERVICE entries to set AUTOTRAN=N.

Changes to the Driver Scripts

Edit driver.sh and populate.sh to change the ud -t 30 argument to ud -d 30.



[Top] [Prev] [Next] [Bottom]