On Wed, Oct 15, 2008 at 9:58 AM, Andrus <kobruleht2@hot.ee> wrote:
> Why you re-invented the wheel?
This is a good point. I guess that you are right. Normally I open
one connection per application (Using a "singleton pattern") and then
pass it to any functions that need it to create or execute a
(prepared) statement. Perhaps ODBC connection pulling would eliminate
this problem, But I want to be sure that I only open one connection
per application.
> If application is idle for a some time, ADSL modems or something other in
> wire closes connection automatically.
>
> There must be some analyzer which closes connection
> only after everything is completed. This requires much more refactoring of
> existing code. so I'm loooking for pool usage.
Aren't pulled connections going to suffer from the same disconnection
problems as nonpulled connections?
Maybe a better solution would be to wrap your connection in a class
that periodically checks if it is alive. If it isn't alive, then
replace the stale connection with a new connection. Also, when
wrapping your connection object you could also have it check and
optionally recreate the dead connection when an operation is requested
from it.
Of course, this won't fix the problem with long running transactions
that might fail when the connection dies, but at least you know that
your connections will always be open. However, using this approach,
you could raise a helpful error message when a connection needs to be
created while a transaction was in process.
--
Regards,
Richard Broersma Jr.
Visit the Los Angeles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug