<div dir="ltr">There are two things to consider here:<div><br></div><div>1. A client is using the database library. Surely, you want some kind of progress in the client. Progress here means that if you time out, you want to do something with the client in question. Maybe it should crash. Maybe it should do something else. There is a *protocol* between the client and the database driver. Clearly, it should be possible for the client to set a timeout on the connection. Also, if the client dies and goes away, the database driver must have a way to clean up after this incident. It can not be the responsibility of the client to do so.</div>

<div><br></div><div>2. The database driver has a TCP/SSL socket to the database server. This transport has some kind of progress as well. It might be that you want to keep the connection alive, or that you know the DB server will send a "I am still processing goddamit!" back to the client once in a while.</div>

<div><br></div><div>These two cases are orthogonal. You can't just set a 10 second timeout, because there will be queries which take longer than 10 seconds to even begin returning result sets (typical if there is a large sort job in the query planner pipeline). On the other hand, you want clients to be able to cancel a currently running query so you can break long-running jobs on the server side.</div>

<div><br></div><div>My hunch is that a good solution is found by:</div><div><br></div><div>* Thinking about crash behaviour. What should happen if a given process crashes?</div><div>* Thinking in terms of protocols. What is the client -> driver protocol? What is the driver -> server protocol?</div>

<div>* Constraining the set of guarantees you give the client. You may have to trade off certain aspects in order to achieve better performance or reliability.</div><div><br></div><div>The Emysql driver mashed these things together and a lot of problems arise from the fact that there is no separation of protocols in it. Suddenly, TCP transport timeouts lingers in the API of the client. Why are they doing that? All of a sudden, if I set `infinity` as a timeout, the result is that a client can be blocked ad infinitum. So the timeout has been pushed back and forth between infinity and some random default value between 3000 and 60000 ms. Also, most Erlang code I have seen written utterly fails handling this by error handling and uses timeout values as a first-principle for handling error. The timeout should be a safety measure to ensure a subsystem has progress. On the other hand, a client which "hangs" on a TCP session until some other event might kill it is not a problem. As long as there is *some* event which can ensure progress in the system.</div>

<div><br></div><div>and that was my 2 cents.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 11:30 AM, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We've been having something of a debate on the epgsql mailing list<br>
about timeouts for database queries:<br>
<br>
<a href="https://groups.google.com/forum/#!topic/epgsql/jmwSCybEN3E" target="_blank">https://groups.google.com/forum/#!topic/epgsql/jmwSCybEN3E</a><br>
<br>
I thought that it'd be interesting to hear how other people handle<br>
things like this.<br>
<br>
One thing that looks like we need is the ability to specify a timeout,<br>
but, beyond that, I just thought I'd ask a wider group of people what<br>
their thoughts are on timeouts in library code like this.<br>
<br>
Thank you,<br>
<span class="HOEnZb"><font color="#888888">--<br>
David N. Welton<br>
<br>
<a href="http://www.welton.it/davidw/" target="_blank">http://www.welton.it/davidw/</a><br>
<br>
<a href="http://www.dedasys.com/" target="_blank">http://www.dedasys.com/</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>J.
</div>