i'm still facing this problem. it only has gotten worse. eventually i get
2,3,4 ibserver processes, together they sum up to 100%. i've eleminated all
spots where transactions could be left open after a crash. after killing all
interserver processes, all connections to the database are closed and still
there remain the ibserver processes. i've found out that shutting down the
database stops the ibserver processes.
here is an extract from top. what i find interesting is that all of these
processes have a high priority number, so they run at lower priority. may it
be that these are garbage collecor threads?
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
2512 firebird 29 0 46700 10M 96 S 21.9 2.1 0:27 ibserver
2513 firebird 32 0 46700 10M 96 R 21.5 2.1 0:39 ibserver
2646 firebird 22 0 46700 10M 96 S 18.5 2.1 0:09 ibserver
2655 firebird 25 0 46700 10M 96 R 18.0 2.1 0:11 ibserver

is it possible that triggers could trigger each other resulting in an
endless loop? i didn't find something like that in the db, tough.

i'm very lost at the moment

the oldest transaction seems to not move forward exactly at the time when
the first ibserver process goes up to 100%. the application is not doing
anything special, just querying records and updating a number that is
counting the number of accesses to a record. is firebird dying because of
too many backversions? when i shutdown i always get the "too many
savepoints" error in interbase.log

>An application that
>(1) selects a set and holds it open all day

doesn't happen. there are only short transactions querying a table of about
5000 records.

>(2) uses CommitRetaining and never hard-commits the transaction

i don't think so. i access the db through interclient and i'm commiting the
trx after use. it is then put back to a connection pool (does interclient do
commitretaining?). closing all connections in the connection pool and
reopening new ones doesn't help, the ibserver processes stay.

>(3) crashes with a bunch of uncommitted work

there is one application putting data into the db. it only runs a few times
a day and doesn't crash.

>An environment where
>(1) DDL is performed on a database while users are active

doesn't happen

>(2) users run a lot of apps simultaneously and keep uncommitted work lying
>around hidden in task-bar icons

it's an online app

>(3) auto sweeping is disabled and nobody runs manual sweeps

sweeps are run every night

>(4) gbak is rarely or never run

gbak is run every night

>(5) users "log out" by hitting the "off" switch

it's an online app

>(6) a reporting app is running huge reports to an overloaded printer queue

no reporting

thanks for any suggestions
michael