--- In firebird-support@yahoogroups.com, "johan_bosaeus"
<johan_bosaeus@...> wrote:

>
> 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
>

After a little more research, we found out that setting the
isc_dpb_dbkey_scope option to 1 in the isc_attach_database call, was
the culprit. The documentation states that if you want the "dbkey" to
be session-wide, set it to 1? We are running several threads against a
database connection, so that sounds right?? Does the database handle
concurrent access to a single database handle, although this options
is set to 0?
Regards,
Johan