Leyne, Sean wrote:

>> Thanks to everyone for their responses. So.. with all this being said,
>> everyone is comfortable that the problem with not committing a
>> transaction and waiting on garbage collection should max out the CPU
>> and degrade performance indefinitely?
>
> YES!!!!
>
> Sean

Yes may sound like a rude answer, but it is a consequence of Firebird
trying to do what it has been told without compromising.

> Oldest active 453
> Oldest snapshot 453
> Next transaction 358860

A gap of 358000 means that all versions of all records affected by these
358000 transactions may be needed. Hence, if each transaction on
average insert/update/delete 100 records, you have 35800000 record
versions that have to be kept under control - even if the last thing you
did was to empty the table. There is nothing saying that transaction 453
will not want to see the version of any record that existed when
transaction 453 started. So, maxing out the CPU is due to (knowingly or
accidentally) having asked Firebird to do some CPU demanding work and
the performance gradually decreases until the problem is corrected.

Firebird is a brilliant database, but taking care of your transactions
is one of the requirements for it to shine.

Set