>> 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 > > >
