This chapter covers the subject of the interface between If you do not have BEA TUXEDO/SQL on your system, you have two options:
Resource Manager Options for bankapp
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.
bankapp
with only a few, relatively minor changes.
These two options are discussed in the two later sections of the chapter.
How you create the This is a 2-step procedure.
The System/D RM and bankapp
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
(If you are bringing up . ./bankvar
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.)
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.
This procedure is quite similar to the one for SHM mode:
As noted above, you may already have done this step.
. ./bankvar
crbankdb
to create the database for this site.
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
.
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.
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.
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.
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.
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.
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.
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.
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
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.
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 -fservicefile
.o -oservername
-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.
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.
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
.
Edit driver.sh
and populate.sh
to change the ud -t 30
argument to ud -d 30
.