El 07/07/2012, a las 15:23, Alan J Davies <alan.dav...@aldis-systems.co.uk> escribió: > > 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.
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]
