Re: [Firebird-devel] Max transaction duration

[Pavel C. <pc...@us...>]

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.

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information