| Subject | Re: [firebird-support] Re: Firebird function to test if a database connection is not disconnected? |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-05-14T01:25:01Z |
At 10:44 AM 14/05/2009, you wrote:
If there hasn't been a detach call, then all the server knows is that there is a database handle in its inbox for something. The client is the one that knows what that "something" is. It refers to any transactions in that session by referring to that handle. Handles exist for the transactions, too, and any statements in that session refer to the transactions they are running in via the appropriate transaction handle.
So, you see, it's only by attempting to refer to (or create) a transaction or statement handle that the client can discover whether it's still "connected". The engine won't know about network interruptions. Dead connections, i.e., those that weren't ended by a client passing a detach request, and haven't responded to keep-alive checks on the db handle, will eventually be cleaned up. In some cases, the transport helps out: for example, a TCP/IP server has timeouts of its own that might kick in before the engine gets around to discovering the absent client.
In the case of a web application, the "client" is the web application: it establishes the connection with the database on behalf of *its* client (your user with a browser in front of him/her). The browser client sends http requests to the web application, not database requests to the db server.
So there's a long explanation for why your web app can't do some service call to the server to find out whether it's still connected. Sending some economical ad hoc query and interpreting the returned error status buffer *is* the way for the client to determine whether its database handle is still alive. "SELECT 1 FROM RDB$DATABASE" is as good as any. If the connection is still alive, you get 1, if it's gone, you get an exception.
When, how and why you'll do this depends on how your webapp is managing connections; and also what you'll do with the browser client's request in response.
./hb
>Still wondering if there is a FB test to see if a connection is disconnected though..."Connected" isn't a server thing, it's a client thing. In a well-regulated world, a client "connects" - that is, it attaches to a database via a server - and it stays connected until it's ready to detach. At that point, it requests a detach. What "connected" means varies according to the transport you use to communicate between the server and the client.
If there hasn't been a detach call, then all the server knows is that there is a database handle in its inbox for something. The client is the one that knows what that "something" is. It refers to any transactions in that session by referring to that handle. Handles exist for the transactions, too, and any statements in that session refer to the transactions they are running in via the appropriate transaction handle.
So, you see, it's only by attempting to refer to (or create) a transaction or statement handle that the client can discover whether it's still "connected". The engine won't know about network interruptions. Dead connections, i.e., those that weren't ended by a client passing a detach request, and haven't responded to keep-alive checks on the db handle, will eventually be cleaned up. In some cases, the transport helps out: for example, a TCP/IP server has timeouts of its own that might kick in before the engine gets around to discovering the absent client.
In the case of a web application, the "client" is the web application: it establishes the connection with the database on behalf of *its* client (your user with a browser in front of him/her). The browser client sends http requests to the web application, not database requests to the db server.
So there's a long explanation for why your web app can't do some service call to the server to find out whether it's still connected. Sending some economical ad hoc query and interpreting the returned error status buffer *is* the way for the client to determine whether its database handle is still alive. "SELECT 1 FROM RDB$DATABASE" is as good as any. If the connection is still alive, you get 1, if it's gone, you get an exception.
When, how and why you'll do this depends on how your webapp is managing connections; and also what you'll do with the browser client's request in response.
./hb