| Subject | Re: [firebird-support] Re: Need clarification on remote firebird connection |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-08-07T13:02:26Z |
At 07:51 AM 7/08/2005 +0000, you wrote:
If the client application is running, an exception will occur in your
application as soon as the application accesses the server for
anything. If, for example, it was fetching rows at the moment the break
occurred, it will respond as soon as a fetch fails.
If the application was processing some sort of data-changing request, all
uncommitted changes will be lost. IBO has the capability to store this
uncommitted work - you will be able to retrieve it and send it again, once
the connection resumes.
Before that can happen, your application will have some work to do, to kill
the broken connection and re-establish the new one. That topic is for the
IBO list, not this one.
If the server loses a client connection, there *is* a timeout. This
timeout is determined by the server's socket keep-alive setting, which is a
network configuration, not a Firebird one. If this keep-alive period
elapses without the server receiving a response from that socket, it will
begin to clean up all of the uncommitted work that was occurring in any
transactions that belonged to that dead connection. Eventually, those
"dirty" record versions will be garbage-collected.
the connection to one server was lost, that was caught in the process of a
two-phase commit or rollback, then that transaction becomes a "limbo"
transaction. The gfix tool can be used to resolve limbo transactions in
each database.
However, a lost connection doesn't corrupt data or cause things to "get
stuck", as far as the database server is concerned.
Of course, if your application doesn't handle the exceptions from the lost
connection, and do what is required to clean up the now invalid connection
and transaction resources, then *it* will get stuck if it tries to pass
anything across that dead connection.
./hb
>Sorry if my previous posting are confusing.If disconnection occurs, data stops flowing.
>
>What I have is a single client (using IBO) application connected to a
>local firebird server and it will also connect to a remote firebird
>server using TCP/IP to check other branch's stock, run queries etc. If
>disconnection occured in the midway of data transfer from the remote
>server, will the remote firebird server get stuck (i.e. keep sending
>the remaining data)?
If the client application is running, an exception will occur in your
application as soon as the application accesses the server for
anything. If, for example, it was fetching rows at the moment the break
occurred, it will respond as soon as a fetch fails.
If the application was processing some sort of data-changing request, all
uncommitted changes will be lost. IBO has the capability to store this
uncommitted work - you will be able to retrieve it and send it again, once
the connection resumes.
Before that can happen, your application will have some work to do, to kill
the broken connection and re-establish the new one. That topic is for the
IBO list, not this one.
If the server loses a client connection, there *is* a timeout. This
timeout is determined by the server's socket keep-alive setting, which is a
network configuration, not a Firebird one. If this keep-alive period
elapses without the server receiving a response from that socket, it will
begin to clean up all of the uncommitted work that was occurring in any
transactions that belonged to that dead connection. Eventually, those
"dirty" record versions will be garbage-collected.
>Do I need to do any database maintenance works on the remote server ifIf you had a single transaction running across both databases at the time
>that occured?
the connection to one server was lost, that was caught in the process of a
two-phase commit or rollback, then that transaction becomes a "limbo"
transaction. The gfix tool can be used to resolve limbo transactions in
each database.
However, a lost connection doesn't corrupt data or cause things to "get
stuck", as far as the database server is concerned.
Of course, if your application doesn't handle the exceptions from the lost
connection, and do what is required to clean up the now invalid connection
and transaction resources, then *it* will get stuck if it tries to pass
anything across that dead connection.
./hb