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

[<psc...@in...>]

On 13 Dec 2002 at 7:16, Daniel Rail wrote:

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

I wonder if we are looking at the whole thing from the wrong perspective.  A stalled 
OIT/OAT causes the engines performance to degrade;  so we are looking for ways 
to not stall the OIT/OAT.  That may not be the right approach,  if we could find a 
way that stalling the OIT/OAT doesn't degrade performance, or at least not as 
quickly then it wouldn't be an issue.  

In the case of a broken link, then we do detect it,  abort it's transactions, and roll 
them back, eventually.  If your application takes too long and you give it the three 
fingered salute (windows), or issue a kill command (unix), then the transactions it 
owns should die with the app.  I think it does this now...

Paul