At 04:34 AM 7/03/2006, Paulo Fagiani wrote:

>Hi there,
>
>I have an production Java application running for about 3 years with
>no problems using Firebird 1.5.0.4290 in Linux. At least for about 3
>months I've not changed a line of code and it was running all right.
>Suddenly, I'm getting the following error once in a while since 3 days
>ago when I try to make a new connection to the database no matter wich
>driver I use (JDBC, IBX, EasySoft, IBExpert trial...):
>
>"Lock conflict on no wait transaction
>cannot start transaction for password database"
>
>It's important to say that for every transaction I open and close a
>connection (for the java app) and if in the time of the error I am
>connected thru any other driver (ex. delphi app that keeps couple of
>connections open) the current connections work fine but not new
>connections will be accepted.
>
>So far, I've found a weird solution, and I hope that this can guide
>you to help me: as I thought that it was at first a db corruption...
>I did a GBAK do back the db up before triying anything... My surprise
>was that as soon as GBAK started to run, all connections began to be
>accepted without any problems... I've tried alredy to backup and
>restore the whole db and to reboot the db server but nothing keeps it
>from once in a while block new connections with the message above.
>Other information is that we have about 4 different databases (gdbs)
>running on this server and when the problem arises it's for all
>databases, not only for the one that the Java app uses... GBAK so does
>something on the server itself... if the command helps here is the
>syntax I use:
>
>gbak -B -USER SYSDBA -PAS masterkey -V /path/to/my/database.gdb mydb.gbk

It's not normal for a lock conflict to occur on the security
database, since it is opened by the firebird engine (by the firebird
user) in exclusive mode for writes; to the rest of the world, it is read-only.

Make sure that you don't have a cron job that's running some utility
in direct-connect mode and for some reason has a lock on
security.fdb; or a user with root privileges using a utility tool
to connect directly to security.fdb, thus denying access to the firebird user.

Have you thought about backing up the security database and restoring
it, first to a temporary file and then, after shutting down the
server, renaming the old security.fdb to something else, and renaming
the restored copy as security.fdb and placing it in /opt/firebird?

It's something you should do anyway, from time to time.

>Something else that I would apreciate if someone has an answer is that
>since we began to work with Interbase and now Firebird that every
>other week we gotta do a backup/restore to keep the db server
>healthy... otherwise it will get nuts somepoint and start to not
>finishing the connection's processes and the server will overload
>memory and processor... then only a backup/restore to solve it...

Run sweeps to clear up the build-up of garbage. Running a backup
does this also (provided you don't use the -g switch) and it's not
necessary to restore.

But, to solve the problem of your garbage building up so much that
the database's GC cannot cope, you'll need to post a few questions on
firebird-java about your application flow and the way you are
managing your connection pool.

./heLen