Re: use of GNATSDB

[Dirk Bergstrom]

On 5/17/2002 5:03 AM, this issued forth from the mind of Lars Henriksen:
> I can't reproduce this behaviour. Whether GNATSDB is set or not, the command
> "pr-edit --lockdb" seems to lock nothing at all. Neither does "pr-edit
> --database=<db> --lockdb". On the other hand, "pr-edit --lock <user> <PR>"
> honors GNATSDB as well as the --database option.

this is a totally different issue.  as you probably know, gnats has two
separate code paths:

"localhost mode", in which the particular program you're running
directly interacts with the database.

"network mode" in which the program talks to gnatsd over a socket.

i could rant extensively about how foolish, wasteful & bug-prone this
is, but i'll save that for another day, and stick to this particular
example of the folly.

so in pr-edit, the "network mode" lockdb code opens a socket to gnatsd
and issues a LKDB command, and gnatsd locks the database.  in "localhost
mode", pr-edit makes a call to gnats_lock() (actually, it calls foo,
which calls bar, which calls gnats_lock), which is the same call that
gnatsd makes.  this *does* lock the database, but then, at the very end
of main(), there's a check that says something like:

if (gnats_locked) {
    unlock_gnats()
}

this check is entirely reasonable, if you're trying to do an edit, or an
append, but it's just wrong if you're trying to lock the database.

so, you happen to have run into one of the many, many subtle and
outrageous bugs in localhost mode.  this is why i counsel people to
*always* use network mode, even when talking to a local database.

how, you ask, do you make sure you're using network mode?  by specifying
either --host or --port or both.

-- 
Dirk Bergstrom                   address@hidden
Computer Geek                     v: 707.433.0564
Juniper Networks Inc.             f: 707.433.0769

"it *looks* like a nail; lemme grab my hammer..."