RE: [Firebird-devel] Max transaction duration

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

On 15 Dec 2002 at 10:14, Leyne, Sean wrote:

> Pavel,
> 
> > Interesting, so server should kill requests in progress when 
> > time ticket expire ? I'd worry to introduce that. 
> 
> But if the implementation, of this proposed feature, had a default of
> "no timeout" what would be the worry?
> 
> It seems that most of the "naysayers" are 'up-in-arms' because they
> are all working on the assumption that the default timeout will be
> something like 60 secs.

The issue isn't the timeout, or timeout period, but whether this fixes the problem or 
just masks the problem.  It's like a toothache, sure the aspirin takes away the pain 
(temporarily), but until you go to the dentist and get the tooth fixed, the problem is 
still there.  In this case the stalling of the OAT is the toothache.

So what can be done about it, first we need to enumerate all of the ways of causing 
a transaction to fail in the middle.  

1) The client machine crashes.
2) Client machine suffers a power off situation.
3) Network cable or device failure.
4) Application fails to commit/rollback the transaction before ending.
5) Application opens a writable transaction and leaves it open for an extended 
period of time.

For causes 1-3 the engine should be able to detect the failure and recover from it, 
by rolling back the transaction and marking it as committed.  This may mean engine 
changes so that only updates that can be reliably rolled back are actually written to 
the database.

For cause #4 when the application ends, without a commit or rollback we need to 
rollback the transaction, and mark it as committed.  

For cause #5, there really isn't much the engine can do about it, applications should 
not do this, the solution is to fix the #@!%$ application, I don't care what the 
application does, it should not behave this way.  I think the solution may be in save 
points and commit retaining which should both allow the engine to throw away the 
no longer needed back versions, effectively advancing the OAT at least logically, 
resolving the problem.  

A timeout may be helpful in making sure that applications are behaving themselves, 
should it kill the transaction, or just warn someone about it (so they can fix the app), 
is the real question.