|
|
Hi all!
Charlie Adams wrote:
>> sorry, I realize that this thread is meant to be over and I guess
>> nobody here knows the answer but don't we have an issue in the use
>> of Postgres in commercial applicationx with regards to remote
>> connections , this happens to me when connecting to my repository
>> at home from work, I have not done anything special on my router
>> but open the Postgres port, which I am pretty sure is the case
>> with Charlie, so special tweaking?
This is not an postgres specific issue. Any tcp connection staying
open for some longer amount of time with no traffic will experience
this issue (as explained in some previous posts).
Since your router in your home box possibly keeps a stateful
connection table (e.g. to do NAT), you experience the same effect
as a stateful firewall will.
>> Is the socket based driver the only way to hook up to Postgres or
>> is it jus the only way VW has to hook up to Postgres.
If you are not using a local repository with Unix Domain Sockets
(dunno, if that is supported by VW), you have to use tcp/ip.
But then you already had a local copy and no hassles with a
network connection.
>> Isn't this an issue? Don't we need an AR? I guess apps can always
>> do re-connects.
Yes, you could but: it is not correct to assume for every
every application, that reconnects are acceptable.
So this had to be done on application level, i.e. Store
would check for timeout on the connection and retry (better only)
once to reconnect. This does not sound like vodoo to me.
Considering the fact, that we have one Store server for the
developer workstations, which never suffers disconnects (I
sometimes discover images forgotten on a test server, because
of weeks old logins to Store), I would vote against a special
solution for this situation. You just have this problem once
in a while, wait for the timeout, do the reconnect and you can
work again.
As some people said, a simple query to the server every 5 minutes
or so could help, e.g. (not really tested)
[ [ (Delay forSeconds: 5*60) wait.
[ Store.DbRegistry storeBroker processSQL: 'select version();'
] on: Error do: [ :ex |].
] repeat ] fork
> Could VW do a sort of "connection-on-demand"? That is, open the
> connection, execute the db transaction and then close the
> connection. So, instead of selecting a connection profile and
> opening the connection, we would merely be selecting a profile to
> be used whenever a connection was required.
>
> I know this puts domain (firewall) knowledge into the client (VW)
> and represents an inappropriate coupling. But it would work. :) It
> takes practically no time at all to connect and disconnect.
Yes, one can change the code to do that, but observing the amount
of queries sent on a single package load, I would guess that the
relogin overhead could be quite a lot, especially if the remote
server is on a low speed connection. Do you want to pay that
overhead all the time? And hopefully no anti-DOS tool will
consider this kind of traffic flooding and block it.
my $0.02
Jan
|
Locked
