| Subject | Re: [firebird-support] Dead connections |
|---|---|
| Author | Helen Borrie |
| Post date | 2010-11-08T00:53Z |
At 09:25 AM 8/11/2010, you wrote:
I suspect the reason you're not getting "useful" answers about this is that you (and others who echoed your problem) forget that transactions and connections are instigated by the client, not the server. The server has no way to tell what is going on at a client. If the server doesn't get a commit or rollback request from a client for a transaction, or a detach request for a connection, then they simply stay alive until the operating system decides the connection is dead.
Your OS will kick in eventually (4 hrs is the default on Windows for considering a non-responding network connection "dead") and inform the server that the connection is gone. After that, the server will tidy everything up, rolling back any open transactions and invalidating the attachment handle. Once they are gone, MON$ queries won't report them any more.
If you have applications that crash frequently, or users who persistently misbehave, you might like to experiment with the network timeout parameters on the host machine to try shortening the dead connection threshold. I forget the name by which Windows refers to it but you should find it with google (as I have done in the past). Windows generally comes with unpublished defaults for network settings so it *will* be a case of adding keys and values to the Registry. That said, the MSDN papers on these topics are pretty comprehensive.
./heLen
>I *think* the transaction is being rolled back and the connection terminatedI see you are dual posting this thread in two lists. May I remind you that firebird-devel isn't for support questions?
>but there are a lot of permutations in the client code so it's possible that
>in some situations this isn't happening. Is there a mechanism with Firebird
>for timing out a transaction or connection that is inactive for a long period
>of time?
I suspect the reason you're not getting "useful" answers about this is that you (and others who echoed your problem) forget that transactions and connections are instigated by the client, not the server. The server has no way to tell what is going on at a client. If the server doesn't get a commit or rollback request from a client for a transaction, or a detach request for a connection, then they simply stay alive until the operating system decides the connection is dead.
Your OS will kick in eventually (4 hrs is the default on Windows for considering a non-responding network connection "dead") and inform the server that the connection is gone. After that, the server will tidy everything up, rolling back any open transactions and invalidating the attachment handle. Once they are gone, MON$ queries won't report them any more.
If you have applications that crash frequently, or users who persistently misbehave, you might like to experiment with the network timeout parameters on the host machine to try shortening the dead connection threshold. I forget the name by which Windows refers to it but you should find it with google (as I have done in the past). Windows generally comes with unpublished defaults for network settings so it *will* be a case of adding keys and values to the Registry. That said, the MSDN papers on these topics are pretty comprehensive.
./heLen