Re: [Firebird-devel] Max transaction duration

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

On 12 Dec 2002 at 20:17, David Jencks wrote:

> > The software should be fixed, a maximum transaction duration, cures
> > the symptom, and not the overall disease, a badly designed app,
> > which probably has other problems as well.
> 
> NO!!  The purpose of timeouts is not to compensate for badly written
> anything, it is to make it possible to write robust distributed
> programs that can continue operating even when some parts crash or
> become unavailable.  If someone removes the lan cable between your
> well written app and the firebird server, either firecbird has to be
> able to recognize that your uncompleted transactions can be rolled
> back, or some person will have to do it. 

If the network connection is severed, whether because someone pulled a Lan cable, 
or the client machine crashed or the power failed, or a storm zapped the client, the 
server detects this situation, and aborts all transactions for that client, eventually 
based on network timeouts.  It's just while waiting for the first row, when it seems to 
not process keep alive packets that it may not notice, this should be logged as a 
bug and fixed if it's true.
 
> > There are a couple of issues, any overall general transaction life
> > routine, will either need too long a period that a transaction can
> > live, or it's going to kill something important.  For example if the
> > year end sales report runs for 17 hours, then you need to set the
> > timeout to at least 18 hours.   This means that ANY transaction can
> > live for 18 hours, if you have 25,000 normal transactions an hour,
> > your still sunk.  
> > 
> Specify the timeout per transaction.  Personally I think the JINI idea
> of renewable leases is the most elegant, but simple timeouts are
> standard in the database world.

This means that the application needs to know that it contains a longer running 
transaction, and it may still be a problem, whether a long running transaction is 
legitimate or not, it causes the same problem, server performance goes down the 
toilet.  Ideally that 18 hour sales report, should be written in such a way, that it 
doesn't need an 18 hour transaction.  IMNSHO we need to find a way to minimize 
the impact of long running transactions, rather then eliminating long running 
transactions.  If a transaction that started in 1997 and is still running, and causes no 
problems then who would really care?

Paul