Re: Keep-alive?

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
> Sent: 10 October 2003 13:53
> To: Dave Page
> Cc: pgadmin-support(at)postgresql(dot)org
> Subject: Re: [pgadmin-support] Keep-alive?
>
>
> Each database has its own connection to the server (just
> checked with netstat), and thus is individually target of a
> firewall surveillance/ forced tcp disconnect.

Good point, same problem as the icmp keep alives.

> > Unless you've changed the code from what I originally wrote, the
> >master connection will never be used for threaded queries.
> >
> Wouldn't make sense to thread them too, but what about
> disconnects on Query Tool, Data Grid etc?

Dunno what you mean by diconnects in that context, but as you pointed
out, requiring the heartbeat on all connections kinda throws the whole
idea in the bin anyway as we couldn't then use asynchronous queries in
those (or other) tools.

I don't see a way around that...

> Deriving from wxFrame doesn't mean it gets events, because
> the default wxFrame constructor won't create a window, so
> it's no window in win32's sense. I just checked the msw
> implementation of wxTimer, it doesn't use the message loop,
> but a callback proc, that's why it's working. Still,
> declaring pgConn to a kind-of window doesn't make me feel too
> comfortable (wxEvtHandler should be sufficient). I'd rather
> like to have the pg classes free of all this sm_xxx stuff.

Deriving from wxFrame was not something that I was overly happy with
either, but it was looking a heck of a lot cleaner in deriving a new
class from wxTimer and overloading the OnTimer member (or whatever it's
called).

Anyway, the reason I posted the patch was to gather ideas and feedback,
not to propose it as a final solution (as your initial comments indicate
you thought). I don't see any way to implement this cleanly at this
layer now so unless you or anyone else has any bright ideas I'll scrub
it from the todo list as unworkable, and move one...

Cheers, Dave.