Hello,

I have a server running 24x7 for some month with out any stop, it
have 120 active conections to the database and the max gap between
the Next Transaction ID value and the Oldest Active & Interesting
Transaction is 3.

The secret is to surelly close any active transaction after use it.
Don't keep any query opened in a non read-only transaction.

With best regards
Christian

--- In firebird-support@yahoogroups.com, "hugh_borst" <hborst@h...>
wrote:

> Hello dear FireBird users;
>
> We are having performance degradation problems with several FireBird
> and InterBase client installations and have searched throughout our
> client application (Delphi 5 and BDE) for long-running (uncommitted)
> transactions without success. We have closely examined the
> interaction between the client and the database and have found that
> when the database slows down, the Next Transaction ID value and the
> Oldest Active & Interesting Transaction values are highly divergent,
> perhaps as far off as 750,000 or more. This state of affairs slows
> the database down dramatically of course.
>
> We expected to find some long running transaction in the client

code,

> but this is not the case. To our surprise, it seems that

transactions

> started on a given connection while other, CONCURRENT connections

are

> running will hold the OAT & OIT from advancing until ALL of those
> connections disconnect, regardless of the fact that all connections
> have committed their transactions. Once all clients have

disconnected

> (including IBConsole), the transaction counters catch up to the next
> transaction value (within one, as expected) without fail.
> Unfortunately, we have some clients whose users are prone to running
> the application for days on end without exiting, much less

rebooting.

> At any rate, we do have a mechanism for forcing the users off of

the

> system, so we figure that we're all set, although we are very
> concerned that the engine is working in this way.
>
> ***
> Would anyone care to confirm to us that this behavior is what should
> be expected from InterBase / FireBird?
>
> Also, is this behavior a necessary aspect of the versioning engine?
> Why can the engine not move the OIT & OAT once the transaction has
> been committed?
>
> Lastly, is this something that can be entered as a bug fix or
> enhancement request for FB 2.0?
> ***
>
> Our configuration varies greatly from client to client but this
> problem is consistent across versions of IB (6.0.2.0 or 7.1) and
> FireBird 1.0.3. The database is hosted on either a Windows 2000
> server or a Red Hat Linux 9 server. All clients are Windows 98 or
> above.
>
> Thanks very much in advance.
>
> Regards,
>
> Hugh J Borst