Re: [Firebird-devel] Max transaction duration

[David J. <dav...@di...>]

umm, I think I've been saying repeatedly that _all- the sources I have seen
on distributed system design say the __only__ reliable way to detect 1--5
is with timeouts on the server.  So far no one has directly disputed this,
just argued with the conclusion that to ensure reliability we should
implement transaction timeouts on the server.

Although many cases of 1--4 can be detected by the current connection
keep-alive/timeout feature, I think this clearly relies very heavily on
unwarranted assumptions about client architecture and good behavior of
clients.

david jencks


On 2002.12.16 15:19:13 -0500 psc...@in... wrote:
> 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.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Firebird-devel mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
> 
>