Maybe a better approach would be to catch the exception when writing to a
socket and in that case flush the pool?
Polling on every connection every 2 secs is a major overhead (especially
for server uses with many connections to multiple databases).
Cheers!
Michał
2015-01-27 12:56 GMT+01:00 Gerdus
The msdn docs do state: "The connection pooler removes a connection from
the pool after it has been idle for a long time, *or if the pooler detects
that the connection with the server has been severed*."
So other database providers probably check periodically for broken
connections.
however the do
Let me copy, once again, the source code of the SW that is not work. Note the
I am always open the Polling connection according the documentation (
https://msdn.microsoft.com/en-us/library/8xx3tyca(v=vs.100).aspx ) and it
was broken since the version 4.6.0.0:
===
using Fire
> I am still trying to understand why it is being considered "expected
> behavior" if due to this issue all of my 122 clients need to be re-start
> their application every time the Firebird Server is Stop/Start or every
> time that we have any network issue.
You live in a dream. There was never co
Don't change anything in your SW because this is not as issue of it.
Use the ADO.NET Provider v.4.5.2.0 that is the lastest version that works
fine.
I am still trying to understand why it is being considered "expected
behavior" if due to this issue all of my 122 clients need to be re-start
their a
Or alternatively you could flush the pool.
Michał
2015-01-23 15:02 GMT+01:00 Nicolas F. Timmers :
> But in this case the pooling problem give the correct would not try a new
> connection from the beginning and no longer use the pooling?
>
> -Mensagem original-
> De: Jiří Činčura [mailto:
