Re[6]: [Firebird-devel] Max transaction duration

[Daniel R. <da...@ac...>]

Hi,




On December 12, 2002 at 8:26 PM, psc...@in... wrote:

> On 12 Dec 2002 at 7:06, Daniel Rail wrote:
>> I was wondering what the new monitor functionality in IB7 was for.
>> That is a better solution.  Also, being able to see what is going on
>> in the transaction would be good too, this is just to make sure not to
>> kill a transaction that is part of a "known" long running process(i.e.
>> year-end processing/reporting).  Unless it would be possible to flag a
>> transaction as one that can take time to complete, compared to others.

> The problem with automatically killing a transaction, or even monitoring a 
> transaction and killing it manually, is that it cures the symptom, but not the under-
> lying disease, which is an application that is taking resources and holding them 
> when it really shouldn't.  It never gets fixed properly, because it becomes easier to 
> simply let it go, and kill the transaction on occasion.

I know that a software that is well written, hardly needs a way to
kill a long running transaction, unless it is totally unexpected.  In
example:  a broken link between client and server due to network
failure, how long does the transaction stays alive and how to kill it
earlier, other than doing a backup and restore.  Also, it would be a
nice feature to monitor transactions when doing the development and
testing, since it's possible to create a query or update statement
that's taking longer than expected and want to kill it in order to
make the necessary corrections and run it again, without having to do
a forced shutdown of Firebird.

> Maybe there are better ways to fix this, for example split the transaction into two 
> processes, one that is application oriented, and one that is engine oriented, a 
> commit retain would then commit and end the engine part of the transaction, and 
> create a new engine part of the transaction assigned to the same application part, 
> so that the long running transaction's process simply does a commit retain, when 
> and where it's logically convenient, and there becomes no need for a long running 
> transaction.

Doesn't Nickolay's save points take care of that?
But what happens if the long running transaction is a year-end report
or a year-end reconciliation, which can take hours.  But, if for some
unforseen reason, you have to cancel that report or reconciliation and
rollback everything, and your own application seems frozen, then you
have to be able to kill it on the server, so that everything is rolled
back.

-- 
Best regards,
 Daniel Rail
 Senior System Engineer
 ACCRA Group Inc. (www.accra.ca)
 ACCRA Med Software Inc. (www.accramed.ca)