Why don't enable auto-reconnect while database connection lost?

[sishen]

Hi.

Sorry for raise an old issue. I have seen the ticket in trac but no answers found.

My database is mysql and when it's idle for a long time, the connection lost and raise some exception.

I have read the mysql_adapter.rb and find it hasn't used the reconnect policy which is allowed by the Mysql Binding.

So why don't enable this feature?  Is this a design choice? 

I think if we allow to set "reconnect: true" in the database.yml, the thing will be better.

Maybe i miss something, thanks for your all advice.

Best regards.

sishen

[sishen]

Should I submit a patch about this? Thanks.

[Courtenay]

afaik Rails runs 

 ActiveRecord::Base.verify_active_connections!

before each request.  Is this broken?

[sishen]

How will this work?  Is this like the before_filter for each connection? 

I prefer this logic:

begin
   connection.query(xx)
rescue StatementInvalid
   reconnect
end

I suppose the mysql reconnect policy follow this way but i'm not sure, :)

[Ryan Bigg (Radar)]

From what I call, Rails does not lose a connection when a StatementInvalid error is thrown.

Can you prove this in a test?

Sorry if I misunderstood your original post, it isn't very clear.

[sishen]

Sorry. I haven't described it well. I use AR only in my app.

The default live time of mysql connection is 8 hours. When the connection is idle for longer than that time, the exception throws.

I think there should be a reconnect policy to auto connect to the server when connection is lost, especially the mysql binding support that, right?

[Michael Koziarski]

> I think there should be a reconnect policy to auto connect to the server
> when connection is lost, especially the mysql binding support that, right?

Yeah, rails applications will do this transparently. We don't want
to have a solution that only works with mysql when the current one
works for all our supported databases.

--
Cheers

Koz

[Jeremy McAnally]

I actually had 3 different people come up to me at MySQLConf and tell
me their AR connections were dropping like this and not reconnecting.
It might be something you want to check into (though I don't think
there's a verifiable way to test it).

I'll try to find out more information from those guys if I can find
their cards...

--Jeremy

--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

[Pratik]

The catch is, if someone is running AR in daemonized env. outside
actionpack, they gotta call verify_active_connections! manually.

--
Cheers!
- Pratik
http://m.onkey.org

[Courtenay]

AR connections timeout and drop, that's how it is. Rails fixes this in a filter. I believe it's documented.

That's why on our tt AIM bot I have to verify connections before each access (but you knew that, jeremy :P ).    As lifo says.

[Michael Koziarski]

> AR connections timeout and drop, that's how it is. Rails fixes this in a
> filter. I believe it's documented.
> That's why on our tt AIM bot I have to verify connections before each access
> (but you knew that, jeremy :P ). As lifo says.

Having said that, there's no reason why the adapter *couldn't* support
a reconnect option, if it's in the mysql client lib. I'd be happy to
take patches for it.

However I certainly wouldn't want to roll our own reconnect-on-error
thing, retrying sql statements is a great way to lose friends and
invalidate data.

--
Cheers

Koz