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
> <Alan.Davies@...
> <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]
>
>