Overall Connection Handling

[reyonman]

I've had this problem since I started using DB Solo about a year ago.
If for some reason my network connection dies (e.g. flaky VPN) I have
a small chance of DB Solo handling the database disconnection
gracefully. On rare occasion I will receive some sort of connection
error, but usually the application will hang and I'm forced to kill it
(hoping I saved my work). My co-worker experiences the same
frustration.

I would really like to see some work go into connection handling in a
future release. This really is my only gripe with DB Solo, an
otherwise great tool.

I don't recall which version we started on, but it was about a year
ago when we bought licenses. I'm currently using 3.7. We both use
Macs. I'm on Leopard, my co-worker is on Tiger.

If there is any additional information I can provide please let me
know.

Thanks!


Ryan

[DB Solo]

What database are you using? Where do you see the tool hanging, schema
browser, query editor or some other place?

Typically you should get a network timeout which should result in a
dialog showing the error. If the timeout is large the tool may 'hang'
until
the networking exception is thrown.

Marko

[reyonman]

I've gotten it with SQL Server and MySql. I typically get the
exception when attempting to execute a query without realizing there
was an issue. Attempting to open the browser tree on the left will
result in the same issue.

Is the timeout user configurable or hard coded?

Ryan

[DB Solo]

Try this with SQL Server. The jTDS JDBC driver has a property you can
override. Select the server connection in the Schema Browser and add a
new JDBC property 'socketTimeout' and set the value to something
reasonable, e.g. 20 (it's in seconds). Click on Update and connect to
the server. Now the connection should time out in 20 seconds.

[DB Solo]

MySQL JDBC driver has the same exact property name socketTimeout. I'm
not sure if it is in seconds or milliseconds, though.

On Fri, Mar 27, 2009 at 9:12 AM, reyonman <reyo...@gmail.com> wrote:
>

[reyonman]

That does correct the issue, however socketTimeout is an overall
timeout and also limits query times. I do occasionally run queries
that run for a couple minutes so this won't work for me.

Is there anything else you can think of? In the case of a network
failure the underlying socket is toast. I'm surprised that an
exception isn't thrown.


Ryan

[DB Solo]

The only way (that I know) to detect a long-running query vs. network
failure is to use TCP keepalive messages. If you configure your OS TCP
stack to use keepalives it should detect the network failure and the
error should be propagated to the JDBC driver. I'm not sure how that
is configured on MacOS. I'm also not sure what the implications for
other apps are if you set it too low. For reference here's how you
would do it on Linux

http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html

[DB Solo]

MySQL JDBC driver seems to have properties for setting the tcp
keepalive (tcpKeepAlive). That only says if keepalives are used or
not, though. You'd still have to configure the actual timeouts at the
OS level, I believe.

http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configuration-properties.html

[reyonman]

I suppose the bigger issue is that it appears the GUI is running in
the same thread as the code using the connection. I wouldn't have an
issue with the connection hanging if I was able to tell the
application to reconnect. I'm really surprised that no one has
reported this previously.

If changing that is too involved or not an architecture change you are
interested in, would you consider an out-of-band application level
"are you alive" query?

Oh, and thanks for being so active in the forum!

Ryan

On Mar 27, 11:50 am, DB Solo <mhant...@gmail.com> wrote:
> MySQL JDBC driver seems to have properties for setting the tcp
> keepalive (tcpKeepAlive). That only says if keepalives are used or
> not, though. You'd still have to configure the actual timeouts at the
> OS level, I believe.
>

> http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-configur...

>
>
>
> On Fri, Mar 27, 2009 at 12:44 PM, DB Solo <mhant...@gmail.com> wrote:
> > The only way (that I know) to detect a long-running query vs. network
> > failure is to use TCP keepalive messages. If you configure your OS TCP
> > stack to use keepalives it should detect the network failure and the
> > error should be propagated to the JDBC driver. I'm not sure how that
> > is configured on MacOS. I'm also not sure what the implications for
> > other apps are if you set it too low. For reference here's how you
> > would do it on Linux
>
> >http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
>

[DB Solo]

I believe this should be fixed now. When you select a server
connection in the Schema Browser, there is a new tab named
'Connectivity'. It has a button that allows you to automatically check
the connection health before each operation (*).
It basically does a simple select (e.g. select getdate() in SQL
Server) in a separate thread before it does the action/query you
performed. If the health check does not return in the allotted time,
an exception is thrown and
you will be presented with a dialog that allows you to try to
re-connect. I don't think this option should be enabled in 'normal'
conditions as there is a performance penalty (both client and server)
associated with creating a separate thread and issuing the
health-check query.

Please download the latest from dbsolo.com/preview and give it a try.

Marko

*) Actually the health check will only be performed if has been more
than 4 seconds since the previous successful health check

[reyonman]

Downloading now. I'll let you know how it goes..

[reyonman]

The changes you've made are working for me.

Thank you!


Ryan