> 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.
Ah - so is reconnecting to the DB handled for me by the connection pool as soon as I try to use the Database object (I tried in the console and it seems to work that way)? The problem here is that I don't think I have any way of running code before fork is called, because it isn't a Daemon I'm writing myself, but Passenger. As far as I can tell from the passenger documentation, this is the only point at which I can hook into the passenger forking/ spawning method. I'm probably being really dense, but why is it important to disconnect before rather than after the fork? AFAIK, the connection won't actually ever be used in the parent process (a passenger ApplicationSpawner), only in child processes - does this make a difference as to whether it matters whether you disconnect pre/post fork? Maybe this is more of a issue for the passenger mailing list. @Aaron > don't forget that there may be a stateful > firewall that is expiring state and denying packets (thus causing the > disconnect). I don't think this is the problem because I have a rails app working on the same setup which works fine. Thanks for everyone's help so far, much appreciated. Cheers, Roland -- 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.
