Subject | Re: [firebird-support] Hanged up transactions |
---|---|
Author | Ramiro Barreca |
Post date | 2010-12-20T16:55:34Z |
The problem is not with TCP connections, but with FB transactions.
Some users do use an app and, after a task the app remains open for a long
time. While it is opened, the transaction appears as STARTED in the
MON$TRANSACTIONS table and in the stats as the OAT.
It must be sure that the developer has not perform a commit after the query
(even selects) or there is a problem whith the connection component of the
app.
The next transactions are kept in the queue waiting for the commit or
rollback command.
Questions are:
1. Is there a parameter for the client connection to use a type of
transaction that can handle better this?
2. Which on is the better transaction model to use (even for selects)?
3. Is there a "magic" way of "suggest" developers to handle transactions
in the right way?
4. Can I automate the kill of TCP connections of not committed
transactions so FB server can rollback them to allow the other clients
continue working?
Ramiro Barreca
2010/12/20 bogdan <bogdan@...>
Ramiro Barreca
rbarreca@...
[Non-text portions of this message have been removed]
Some users do use an app and, after a task the app remains open for a long
time. While it is opened, the transaction appears as STARTED in the
MON$TRANSACTIONS table and in the stats as the OAT.
It must be sure that the developer has not perform a commit after the query
(even selects) or there is a problem whith the connection component of the
app.
The next transactions are kept in the queue waiting for the commit or
rollback command.
Questions are:
1. Is there a parameter for the client connection to use a type of
transaction that can handle better this?
2. Which on is the better transaction model to use (even for selects)?
3. Is there a "magic" way of "suggest" developers to handle transactions
in the right way?
4. Can I automate the kill of TCP connections of not committed
transactions so FB server can rollback them to allow the other clients
continue working?
Ramiro Barreca
2010/12/20 bogdan <bogdan@...>
>--
>
> Sorry - top post, i hope Helen will not be too angry (I like Top posting a
> lot more than the other option - no time at all and problems linked one to
> another
> and all problems on-line (in my head of course))
>
> TCP keep alive - very well - i just couldn't resist.
>
> Sorry Helen
>
> Bogdan
>
>
> From: firebird-support@yahoogroups.com<firebird-support%40yahoogroups.com>
> [mailto:firebird-support@yahoogroups.com<firebird-support%40yahoogroups.com>]
> On Behalf Of Michael Ludwig
> Sent: Monday, December 20, 2010 2:17 PM
> To: firebird-support@yahoogroups.com <firebird-support%40yahoogroups.com>
> Subject: Re: [firebird-support] Hanged up transactions
>
>
> Ramiro Barreca schrieb am 20.12.2010 um 09:39 (-0300):
>
>
> > I need to know if there is a server parameter to manage this idle
> > attachments or really finished but appears as STARTED.
>
> Do a web search for: Windows TCP Keepalive.
>
> Incidentally, the first match I found (German) mentions Firebird:
>
> http://www.consic.de/support/keepalive.htm
>
> (Just in case you wonder, the girl on the photo is Germany's top expert
> on Windows TCP Keepalive. :-)
>
>
> > Is there some other recommendations to the development team to manage
> > transactions better to avoid this problems.
>
> Ensure committing or rolling back transactions, for example by a proven
> code template for your development language, or by paying close
> attention to always clean up in a "finally" block.
>
>
> > Our platform:
> > Windows 2003 server R2
> > FB superserver 2.1.1.179
> > client apps: VB, Delphi, IBexpert
> > around 500 concurrent clients.
>
> --
> Michael Ludwig
>
> [Non-text portions of this message have been removed]
>
>
>
Ramiro Barreca
rbarreca@...
[Non-text portions of this message have been removed]