http://www.computerworld.com/s/article/9234747/YouTube_scales_MySQL_with_Go_code

I agree in general. The work I’m doing is read-only polling the server for information. There was a suggestion to enable auto-reconnect by default in Percona Toolkit a while ago, and my response was an unequivocal no because a lot of the work it does is quite sensitive to connection state.

I’ll have to look into the auto-reconnect in the Go driver if I see a situation where I’d like to use it for something that is stateful or not read-only. It does have some facilities for determining if a transaction is valid, but I haven’t examined that deeply.

I’m not a big fan of auto-reconnect in drivers – I think it encourages people to neglect important aspects of connection state that are lost when connections die. I haven’t looked into the Go library at all, but it’s hard for me to imagine that the Go driver solves these problems. I wrote a blog post about this a while back related to Connector/J:

http://mysqlblog.fivefarmers.com/2010/07/05/do-you-really-want-autoreconnect-to-silently-reconnect/

Maybe there’s nothing “silent” about Go’s reconnect functionality, and developers are forced to think through the consequences of failed connections. My experience has been that reconnect capability enables such problems to be ignored.