Re: [Firebird-devel] Max transaction duration

[Phil S. <ph...@sh...>]

On Friday 13 December 2002 15:16, David Jencks wrote:

Hi,

> > When a 'Client' crashes, or the LAN cable is pulled out etc, Firebird
> > will
> > (eventually) notice, close the connection and rollback any open
> > transactions.
>
> Can you prove that any client
> side failure that results in the client ceasing to communicate commits to
> its open transactions will quickly result in connection failure? 

FB will, eventuallty, close the connection, wether it is quick enougth or not 
is another story, a quick test just now removing the network cable and 
looking at the DB stats indicate it took just over a minute to 
close/rollback.  

> The purpose of timeouts is not to interfere with peoples work, but to
> provide a way to automatically recover from remote node  failures.  Some of
> these are taken care of by "broken connection detection" but I'm not
> convinced all possible failures will be detected this way. 

I would argue that all of these failures should be handled by "broken 
connection detection", and if they are not, that area of the code should be 
improved rather than adding another 'feature' to work around it.  

> Since
> transaction timeouts appear to be an industry standard (specified in xa)
> and extremely useful I'm having trouble understanding why there is so much
> opposition. 

I don't know the xa spec, but I think the reason for the opposition is the 
way FB transactions 'should be used', which is, in my view, any open, idle 
transactions are a design flaw of the 'client' application.

You have a valid comment about 'client' crashes not being detected, but I 
think for those cases the 'connection detection' should be improved.

> I'm certainly not suggesting that the default behavior change,
> just that it be possible to supply a transaction timeout with transactions

Surely, when you start a transaction, you know that you are going to 
commit/rollback a 'few lines of code' later after you have inserted a record 
or something, so unless you think you might forget to put a 'commit' in the 
code, I can't see a valid reason for a timeout paramter

> I don't think this would affect delphi users who wish to allow
> indefinite-length browsing sessions with  open transactions,

Anything to prevent this would be a good thing IMO

Phil

-- 
Linux 2.4.4-4GB
  2:00pm  up 9 days, 20:27,  1 user,  load average: 0.17, 0.08, 0.01