Subject | isc_start_transaction following isc_attach_database creates bad "trans leak" |
---|---|
Author | johan_bosaeus |
Post date | 2008-10-27T11:02:15Z |
Hello,
We are running Firebird 2.0.3 in a multithreaded, embedded, 24/7,
application, using Classic server, in a C++ environment.
We noticed that the OIT and OAT doesn't increase as transactions were
committed when starting the application with an existing database. If
we let the application create the database, it works fine, so it
seems that there is a transaction that isn't properly committed, in
the former case.
Using isc_database_info() and isc_transaction_info(), we have narrowed
down the problem to:
1) If we create the database and then starts the transaction
immediately after, active transactions = 1. Which is expected. The
transaction ID is bumped up as expected.
2) If we open the database and then starts the transaction, active
transaction = 2!!!!!!!!! Transaction ID is bumped up in the same way
as above.
Then OIT and OAT are "stuck" for the remaining time the application is
up-and-running, which is absolutely unacceptable. It will slow down,
and performance is of uttermost importance.
Somebody there who can give us a hint,
Johan Bosaeus
Weird-Solutions
We are running Firebird 2.0.3 in a multithreaded, embedded, 24/7,
application, using Classic server, in a C++ environment.
We noticed that the OIT and OAT doesn't increase as transactions were
committed when starting the application with an existing database. If
we let the application create the database, it works fine, so it
seems that there is a transaction that isn't properly committed, in
the former case.
Using isc_database_info() and isc_transaction_info(), we have narrowed
down the problem to:
1) If we create the database and then starts the transaction
immediately after, active transactions = 1. Which is expected. The
transaction ID is bumped up as expected.
2) If we open the database and then starts the transaction, active
transaction = 2!!!!!!!!! Transaction ID is bumped up in the same way
as above.
Then OIT and OAT are "stuck" for the remaining time the application is
up-and-running, which is absolutely unacceptable. It will slow down,
and performance is of uttermost importance.
Somebody there who can give us a hint,
Johan Bosaeus
Weird-Solutions