No, I that is not the cause of the problem, but for my understanding 1 single transaction should not take so long, simply he should try to separate the transactions for self-actions and with it I believe that they avoid several types of problems.

Best Regards
=========
|| ISMAEL ||
=========

----- Original Message -----
From: Tomasz Tyrakowski
To: firebird-support@yahoogroups.com
Sent: Wednesday, October 19, 2011 12:26 PM
Subject: Re: [firebird-support] Firebird Program loses network connection



On 2011-10-19 15:22, Ismael L. Donis Garcia wrote:
> For me you should check the logic of the program because that is long time for a transaction.
>
> try try
> Transaction.StartTransaction;
> Query.ExecSQL;
> Transaction.Commit;
> except on e:exception do
> begin
> .....
> Transaction.Rollback;
> end;
> end;
> finally
> Transaction.EndTransaction;
> end;
>
> This should delay fractions of a second.

Hmm... where do you draw this conclusion from? In my opinion, your
Query.ExecSQL can take an unspecified amount of time, depending on what
the actual query does. I've got a couple of apps, which execute stored
procedures in FB database (which in turn end up generating some hundreds
of thousands of new records) via EXECUTE PROCEDURE statements, which
take a good couple of minutes to complete. Of course there are worker
threads on the client side and such, but the client connection is
blocked until a procedure returns. So I wouldn't be so haste to blame
the client code.

regards
Tomasz

>
> Best Regards
> =========
> || ISMAEL ||
> =========
> ----- Original Message -----
> From: Norman Dunbar
> To: firebird-support@yahoogroups.com
> Sent: Wednesday, October 19, 2011 3:27 AM
> Subject: Re: [firebird-support] Firebird Program loses network connection
>
>
>
> Morning all,
>
> > I have encountered a weird network problem and have no idea what might be the cause of it.
> As far as I'm concerned, all network problems are weird! ;-)
>
> > ...
> > Client connection path to the database is using TCP/IP
> > Situation: Client's program frequently shows
> > Error writing data to the connection
> > An existing connection was forcibly closed by the remote host
> That sounds to me as if the server end is killing the connection as
> opposed to the connection being "lost" due to nnetwork problems or the
> client end failing for some reason.
>
> > Client stated it happened after using the program for some time.
> > As testing, I tried saving couple of big transaction on the client computer and will encountered the same error. Note: Processing time for the transaction takes less then 3 mins.
> Is the transaction doing something CPU intensive, for example a huge
> sort? If so, it's possible that there is no keep-alive on the network
> and some configuration option on the server is killing off "dead"
> connections.
>
> This is something I get occasionally with my Oracle database servers at
> work. They are configured (and I know not how!) to drop dead connections
> after a certain time. When the clients submits a huge CPU intensive
> transaction, it runs and then because there's no network traffic, the
> server assumes the connection has died and drops it.
>
> When the application tries to talk again to the server, it gets the
> message that you are seeing - force closed by remote host.
>
> > ...
>
> > Testing on network so far shows it is stable.
> Probbaly because there is plenty of traffic during the test. You need to
> have a connection initiate with the server and then, do nothing.
> Possibly an SSH to the server could be made and then simply left alone
> to see if it too dies? Of course, you need to try to get a response from
> the server in order to know if it has died or not which means that you
> have effectively reset the aliveness of the connection.
>
> > Perform test by pinging the server and then transferring file to the server while the program is running. Will get the same error above but ping and file transfer continue without hiccup.
> I think, but I'm not a network guru, that ping uses UDP which is not TCP.
>
> > Perform another test by having two program open. Only the program running the test above will crashed with error and the second program can continue being used without any problem.
> Do both programs run the same large transaction? What happens if both
> do? I predict both will lose the connection. Also, when the client is
> running the large transaction, what does Task Manager show for the
> client app - I suspect Not Responding, but I might be wrong.
>
> And also, while the transaction is running, check the network traffic
> (start->settings->Network and Dialup connections, double click on LAN
> and see what's happening) - are you seeing sent/received clocking up
> packet counts while the transaction is running - at the same rate as
> before the transaction? Obviously there will be background traffic -
> your email, other stuff, but you might get a clue. Maybe!
>
> > ...
>
> > Also suspected something is not right with the program but running the same test at my own office with lower end computer and much heavier transaction will not have any problem. I pretty much given up and not sure what so unique about this client network that keep getting this error.
> As I said, I'm not a network guru, but it does sound familiar. I suspect
> that the server has been configured, somehow, to kill off dead
> connections and your long running transaction is thought to be dead.
>
> When you did your test on the low spec machine, were you running exactly
> the same transaction or a different one? Anything that talks across the
> network while running is going to stay alive, anything that hits the
> server for a long period of CPU, for example, is possibly going to be
> dropped.
>
> I reapet, I'm not a network guru and I'm sure others will jump in and
> assist you here, but the above may be worth considering.
>
> And finally, the following sage advice comes from the firebird.conf file:
>
> # Normally, Firebird uses SO_KEEPALIVE socket option to keep track of
> # active connections. If you do not like default 2-hour keepalive
> # timeout then adjust your server OS settings appropriately. On
> # UNIX-like OS's, modify contents of /proc/sys/net/ipv4
> # /tcp_keepalive_*. On Windows, follow instrutions of this article:
> # http://support.microsoft.com/default.aspx?kbid=140325
>
> As Ann would say, good luck!
>
> Cheers,
> Norm.
>
> --
> Norman Dunbar
> Dunbar IT Consultants Ltd
>
> Registered address:
> Thorpe House
> 61 Richardshaw Lane
> Pudsey
> West Yorkshire
> United Kingdom
> LS28 7EL
>
> Company Number: 05132767
>
>
> .
>
>
>
> [Non-text portions of this message have been removed]
>
>

--
__--==============================--__
__--== Tomasz Tyrakowski ==--__
__--== SOL-SYSTEM ==--__
__--== http://www.sol-system.pl ==--__
__--==============================--__




[Non-text portions of this message have been removed]