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
on 13.05.2008 14:14
on 16.05.2008 09:03
Should I submit a patch about this? Thanks.
on 16.05.2008 09:07
afaik Rails runs ActiveRecord::Base.verify_active_connections! before each request. Is this broken?
on 16.05.2008 09:21
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, :)
on 16.05.2008 09:25
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.
on 16.05.2008 11:30
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? On Fri, May 16, 2008 at 3:24 PM, Ryan Bigg (Radar) <radarlistener@gmail.com>
on 17.05.2008 02:16
> 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
on 18.05.2008 01:55
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 On Fri, May 16, 2008 at 8:15 PM, Michael Koziarski <michael@koziarski.com> wrote: > > Koz > > > > -- 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
on 18.05.2008 01:56
The catch is, if someone is running AR in daemonized env. outside actionpack, they gotta call verify_active_connections! manually. On Sun, May 18, 2008 at 12:54 AM, Jeremy McAnally <jeremymcanally@gmail.com> wrote: > >> -- > http://jeremymcanally.com/ > > > -- Cheers! - Pratik http://m.onkey.org
on 18.05.2008 07:03
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.
on 18.05.2008 08:03
> 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. >> > It might be something you want to check into (though I don't think >> >>> I think there should be a reconnect policy to auto connect to the >> >> >> > >> > > > -- Cheers Koz