Re: [Firebird-devel] Max transaction duration

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

On 2002.12.13 04:21:59 -0500 Pavel Cisar wrote:
> Favid,
> 
> On 12 Dec 2002 at 17:57, David Jencks wrote:
> 
> > > I didn't think that transaction timeout itself is not useful or
> needed in
> > > some cases, but there is no need to implement it at database engine
> level
> > > as flat transaction behaviour. Your distributed transaction manager
> can 
> > > easily implement this without any change in database engine.
> > 
> > I don't see how.  Unless the resource manager can discard timed out
> work
> > automatically, someone has to do it manually.  If the tm crashes, it
> will
> > have no record of transactions that have been started but not prepared,
> and
> > will not be able to instruct the resource manager to forget them: there
> > could be other tms that are responsible for them and are still actively
> > using them.
> > 
> > Please explain how the abandoned work on the resource manager will get
> > cleaned up automatically in this case unless the rm can unilaterally
> > discard it based only on information it knows.
> 
> Well, I'm not completely aware about all intimate details in this design,
> 
> especially about various dependencies, but...
> 
> Transactions are bound to connections. If connection or connection 
> manager crashes, transactions are rolled back automatically. You need to 
> implement trn. timeout "controller" close to the connection, so they 
> would crash together if at all, so db engine "takes over" to rollback the
> 
> transaction. If special handling is needed, the timeout controller have 
> to expose an API to trn. manager (if they are not the same) or other 
> subsystem that starts transactions with timeout. If connection between 
> timeout manager and other modules is broken, timeout manager "expires" 
> the transaction(s).
> 
> In your design, the "timeout controller" should probably belong to 
> resource manager, and yes, it can expire transactions automatically when 
> trn. manager goes down.


Resource manager == database == firebird engine:-)

While it might be possible to  put a timeout manager on the client side of
the connection, I dont' think there is any way to make it as reliable as
putting it on the engine/server side.  I think there will always be some
failure modes where the connection is not killed but the remote timeout
manager stops working.

I think your argument at root is that the "lost connection" detection by
firebird is sufficient to detect problems.  I dont'  completely know how
this works but think it is based on a heartbeat of some kind, pinging the
clients.  is this correct?

I still think that transaction timeouts would be a really useful  and
standard feature, although they don't appear to fit in the Delphi
transaction model if I remember correctly.

thanks
david jencks

> 
> Best regards
> Pavel Cisar
> http://www.ibphoenix.com
> For all your upto date Firebird and
> InterBase information
> 
> 
> 
> -------------------------------------------------------
> 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
> 
>