>> If you've found the source, share it with us. Was it a major fault in
>> Firebird, as you originally thought? Or an error in your, or your
>> programmer's, logic?
>> Alan
>>
>> Alan J Davies
>> Aldis
>>
> The error was not in Firebird, was in our programmer logic. I have used the trace manager (thanks to that utility) to see whats happening in the backstage. I have seen that there is one query that is continuosly executed, and for each execution opens a transaction.

The Trace API is an underestimated new feature in 2.5, but a godsend to
analyze such situations.

Sounds a bit like running the query in a transaction with auto commit
turned on. You might see COMMIT_RETAIN in the trace output for an
auto-committed transaction, as this usually is the default option in the
various access layers when using auto commit.

Btw, if this is a very frequently executed query, you could try to run
the transaction in READ COMMITTED and READ ONLY, which doesn't impact
the server negatively, even if the transaction is running for a longer
period.


--
With regards,
Thomas Steinmaurer
http://www.upscene.com/

> Is a web page that shows a master detail information. For each detail row, once the master and detail records are loaded, opens a transaction runs a query and close query and transaction.
>
> This morning, that is a day of not so much work, is around 1/6 of a normal day, monitoring the server, the process opens 2.5 transactions/second and runs the query in each transaction and sometimes, for one detail row, the transaction/query is executed 2 times.
>
> In a normal day, that process can be multiplied by 10 in peaks, that implies 25 transactions/second plus the normal run of the user requests.
>
> May be Firebird is out of resources with the current configuration, and that amount of work.
>
> In a first sight, i thought there was a problem with Firebird, because I saw so much transactions increments (for example 20000 transactions in one minute), and i could not think that the source of the error was web page problem. What also confused me was that there was transaction numbers higher with timestamp lower than transactions with lower transaction_id.
>
> The programmer error is there for months, but until 3 days ago Interbase was running.
>
> I'm going to check others customers logs, to see if the error is recorded, but all our customers, except this one and another, uses superserver, and they have less loaded systems.
>
> Hope this will help someone, because I have seen threads in this list talking about jumps in transactions ID.
>
> Jesus
>
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>