Subject Re: Restart fixes performance issues
Author Adam
--- In firebird-support@yahoogroups.com, "rodrigogoncalves"
<keitarobr@g...> wrote:
>
> >
> > Rodrigo,
> >
> >
> >
> > There is unfortunately no simple way of tracing such behaviour
through
> > your application. If you have a test database to use, you can
write
> > yourself a shell that creates and commits a new transaction every
100
> > ms or so, then look for particular behaviour that sticks the
> transactions.
> >
> > Adam
> >
>
>
> Hi,
>
> thanks for answering. I've already done a test with
> commit/commitRetaining and indeed they perform different (sadly).
>
> Is there a way to prevent the long running transactions from
existing?

That would be very bad if it did. Coming from a BDE background, you
may not fully appreciate transactions (I didn't before moving across
to Firebird). Transactions in Firebird are ACID compliant. They
define an Atomic operation. That means that any queries run either
all run, or none of them run. If there is a problem, crash, power
loss, whatever mid transaction, then the whole transaction is rolled
back.

So it is not really up to the server to decide when the transaction
is too long. The nature of MGA means that the longer the transactions
run, or more correctly, the more transactions that are started since
the transaction started, the more record versions will need to be
maintained, and the more garbage gets prevented from trapped.


> I've thought about a way to prevent long running transactions on the
> main part of our application, but for minor parts it would be a lot
of
> work. If we could just kill the long running transaction, we would
be
> able to trace where this is happening and prevent that. Maybe a
> magical parameter of firebird.conf? :-)

No, see above. What would be useful would be a mechanism to identify
some information about the stuck transaction (MAC address of the
connection, user name, role, time started etc would be a good start
in many cases of identifying the long transactions.

I do wish my news was better, but at least you have a starting point.

Adam