Berkeley DB and Tuxedo

Question

Dear all,
I am trying to set up Berkeley DB from Sleepycat Software (an open
source database implementation) as a backend database for Tuxedo with
X/Open transaction support on a HP-UX 11 System. According to the
documentation, this should work. I have successfully compiled and
started the resource manager (called DBRM) and from the logs
everything looks fine.
The trouble starts, however, when I try to start services that use
DBRM. The startup call for opening the database enviroment ("database
enviroment" is a Berkeley DB specific term that refers to a grouping
of files that are opened together with transaction support) fails with
the error message
error: 12 (Not enough space)
Some digging in the documentation for Berkeley DB reveals the
following OS specific snippet (DBENV->open is the function call that
causes the error message above):
<quote>
An ENOMEM error is returned from DBENV->open or DBENV->remove.
Due to the constraints of the PA-RISC memory architecture, HP-UX
does not allow a process to map a file into its address space
multiple times. For this reason, each Berkeley DB environment may
be opened only once by a process on HP-UX, i.e., calls to
DBENV->open will fail if the specified Berkeley DB environment
has been opened and not subsequently closed.
</quote>
OK. So it appears that a call to DBENV->open does a mmap and that
cannot happen twice on the same file in the same process. Looking at
the source for the resource manager DBRM it appears, that there is
indeed a Berkeley DB enviroment that is opened (once), otherwise
transactions would not work. A ps -l on the machine in question looks
like this (I have snipped a couple of columns to fit into a newsreader):
UID PID PPID C PRI NI ADDR SZ TIME COMD
101 29791 1 0 155 20 1017d2c00 84 0:00 DBRM
101 29787 1 0 155 20 10155bb00 81 0:00 TMS_QM
101 29786 1 0 155 20 106d54400 81 0:00 TMS_QM
101 29790 1 0 155 20 100ed2200 84 0:00 DBRM
0 6742 775 0 154 20 1016e3f00 34 0:00 telnetd
101 29858 6743 2 178 20 100ef3900 29 0:00 ps
101 29788 1 0 155 20 100dfc500 81 0:00 TMS_QM
101 29789 1 0 155 20 1024c8c00 84 0:00 DBRM
101 29785 1 0 155 20 1010d7e00 253 0:00 BBL
101 6743 6742 0 158 20 1017d2e00 222 0:00 bash
So every DBRM is started as its own process and the service process
(which does not appear above) would be its own process as well. So how
can it happen that mmap on the same file is called twice in the same
process? What exactly does tmboot do in terms of startup code? Is it
just a couple of fork/execs or there more involved?
Thanks for any suggestions,
Joerg Lenneis
email: [email protected]

Answer 1

Peter Holditch:
Joerg,
Comments in-line.
Joerg Lenneis wrote:[snip]
I have no experience of Berkley DB. Normally the xa_open routine provided by
your database, and called by tx_open, will connect the server process itself to
the database. What that means is database specific. I expect in the case of
Berkley DB, it has done the mmap for you. I guess the open parameters in your
code above are also in your OPENINFO string in the Tuxedo ubbconfig file?
It does not sound to me like you have a problem.Fortunately, I do not any more. Your comments and looking at the
source for the xa interface have put me on the right track. What I did
not realise is that (as you point out in the praragraph above) a
Tuxedo service process that uses a resource manager gets the
following structure linked in:
const struct xa_switch_t db_xa_switch = {
"Berkeley DB", /* name[RMNAMESZ] */
TMNOMIGRATE, /* flags */
0, /* version */
__db_xa_open, /* xa_open_entry */
__db_xa_close, /* xa_close_entry */
__db_xa_start, /* xa_start_entry */
__db_xa_end, /* xa_end_entry */
__db_xa_rollback, /* xa_rollback_entry */
__db_xa_prepare, /* xa_prepare_entry */
__db_xa_commit, /* xa_commit_entry */
__db_xa_recover, /* xa_recover_entry */
__db_xa_forget, /* xa_forget_entry */
__db_xa_complete /* xa_complete_entry */
This is database specific, of course, so it would look different for,
say, Oracle. The entries in that structure are pointers to various
functions which are called by Tuxedo on behalf of the server process
on startup and whenever transaction management is necessary. xa_open
does indeed open the database, which means opening an enviroment
with a mmap somwhere in the case of Berkeley DB. In my code I then
tried to open the enviroment again (you are right, the OPENINFO string
is the same in ubbconfig as in my code) which led to the error message
posted in my initial message.
I had previously thougt that the service process would contact the
resource manager via some IPC mechanism for opening the database.
>>
>>
If I am mistaken, then things look a bit dire. Provided that this is
even the correct thing to do I could move the tx_open() after the call
to env->open, but this would still mean there are two mmaps in the
same process. I also need both calls to i) initiate the transaction
subsystem and ii) get hold of the pointer DB_ENV *env which is the
handle for all subsequent DB access.
In the case or servers using OCI to access Oracle, there is an OCI API that
allows a connection established through xa to be associated with an OCI
connection endpoint. I suspect there is an equivalent function provided by
Berkley DB?There is not, but see my comments below about how to get to the
Berkeley DB enviroment.
[snip]
I doubt it. xa works because xa routines are called in the same thread as the
data access routines. Typically, a server thread will run like this...
xa_start(Tuxedo Transaction ID) /* this is done by the Tux. service dispatcher
before your code is executed */
manipulate_data(whatever parameters necessary) /* this is the code you wrote in
your service routine */
xa_end() /* Tuxedo calls this after your service calls tpreturn or tpforward */
The association between the Tuxedo Transaction ID and the data manipulation is
made by the database because of this calling sequence.OK, this makes sense. Good to know this as well ...
[snip]
For somebody else trying this, here is the correct way:
==================================================
int
tpsvrinit(int argc, char *argv[])
int ret;
if (tpopen() < 0)
     userlog("error tpopen");
userlog("startup, opening database\n");
if (ret = db_create(&dbp, NULL, DB_XA_CREATE)) {
     userlog("error %i db_create: %s", ret, db_strerror(ret));
     return -1;
if (ret = dbp->open(dbp, "sometablename", NULL, DB_BTREE, DB_CREATE, 0644)) {
     userlog("error %i db->open", ret);
     return -1;
return(0);
==================================================
What happens is that the call to the xa_open() function implicitly
opens the Berkely DB enviroment for the database in question, which is
given in the OPENINFO string in the configuration file. It is an error
to specify the enviroment in the call to db_create() in such a
context. All calls to change the database do not need an enviroment
specified and the calls to begin/commit/abort transactions that are
normally used by Berkeley DB which use the enviroment are superseded
by tpopen(), tpclose() and friends. It would be an error to use those
calls anyway.
Thank you very much Peter for your comments which have helped a lot.
Joerg Lenneis
email: [email protected]