That's really useful for us all and well explained. It also highlights the attention we need to pay to transactions. Thanks Jesús. Alan
Alan J Davies Aldis On 07/07/2012 15:09, Jesús García wrote: > El 07/07/2012, a las 15:23, Alan J Davies > <[email protected] > <mailto:Alan.Davies%40aldis-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] > >
