Subject | Re: Restart fixes performance issues |
---|---|
Author | Adam |
Post date | 2005-10-27T02:56:36Z |
--- In firebird-support@yahoogroups.com, "rodrigogoncalves"
<keitarobr@g...> wrote:
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.
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
<keitarobr@g...> wrote:
>through
> >
> > Rodrigo,
> >
> >
> >
> > There is unfortunately no simple way of tracing such behaviour
> > your application. If you have a test database to use, you canwrite
> > yourself a shell that creates and commits a new transaction every100
> > ms or so, then look for particular behaviour that sticks theexisting?
> 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
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 theof
> main part of our application, but for minor parts it would be a lot
> work. If we could just kill the long running transaction, we wouldbe
> able to trace where this is happening and prevent that. Maybe aNo, see above. What would be useful would be a mechanism to identify
> magical parameter of firebird.conf? :-)
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