On Jan 6, 8:29 am, Roland Swingler <[email protected]> wrote: > > If you are only getting > > the disconnect because the connections aren't being used > > I had a look and the default wait time sequel defines is a month, so I > don't think this is the cause of the problems
OK. If you are getting the disconnects right away, it's probably because you opened the connections before forking and have multiple processes using them. > > Another reason is that implicit reconnection can cause the same > > statement to be executed twice, leading to problems with non- > > idempotent statements. > > I didn't know that - do you know if that is that a general mysql issue > or just an issue with Sequel? (wondering whether I should be removing > the reconnect: true option from my various ActiveRecord-related > projects) AFAIK, it's a general issue with how implicit reconnection has to work. The fact that it's turned off by default should mean something. > > In terms of forking, as long as you disconnect all database > > connections before forking, you should be OK. > > I've had a look through the passenger docs, and am now doing something > like this in my config.ru > > if defined?(PhusionPassenger) > PhusionPassenger.on_event(:starting_worker_process) do |forked| > if forked > # We're in smart spawning mode, need to reopoen DB connections > DB.disconnect > DB = Sequel.connect(...) > end > end > end This code looks like you are attempting to disconnect after the fork, instead of before forking. Also, you don't need to call Sequel.connect again, just DB.disconnect should be enough. But make sure it is called before forking, not after. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
