Closed jasonmk closed 10 years ago
It’s not just the prepared statements that break, all connections break too. This, along with workarounds for Passenger, Unicorn and other environments, is documented in the readme.
Fly-weight prepared statements would unfortunately not be enough. Forking breaks multiple things: the thread running the IO reactor and the sockets, for example.
There should be a reconnect method on Client, but there isn’t, if there was it could work. Currently you need to create a new Client instance after you fork and it won’t have references to prepared statements created by the previous client, and the old statements don’t know about the new client.
Adding reconnect to Client is on my todo, but it’s surprisingly hard to get right.
On 3 jul 2014, at 18:00, "Jason M. Kusar" notifications@github.com wrote:
I'm not sure if this is an issue that can be fixed, or just something that should be added to the documentation (I assume the latter). If you fork a process (like Passenger does) and re-establish a connection, any prepared statements you had lying around won't work in the child process. You have to throw them away and start fresh. I imagine if your fly-weight transaction enhancement ever happens, this could be taken care of automatically.
— Reply to this email directly or view it on GitHub.
Right, I saw the section in the readme and I've been doing that for connections. But then I discovered that prepared statement break too. Just figure it might be worth a footnote in that section listing the other things that you need to re-create in addition to the connection.
Sure, if you interpreted it that way others might too. Since it says you need to reconnect I thought it was clear. If you have a suggestion for what it could say to make it more clear I would be grateful for a pull request, or just paste it here and I'll include it.
Once I thought about it, I realized the prepared statement must have a connection inside of it since you're calling execute directly on it, but I still think a note in the readme calling it out would be helpful to people. I'll send a pull request.
I'm not sure if this is an issue that can be fixed, or just something that should be added to the documentation (I assume the latter). If you fork a process (like Passenger does) and re-establish a connection, any prepared statements you had lying around won't work in the child process. You have to throw them away and start fresh. I imagine if your fly-weight transaction enhancement ever happens, this could be taken care of automatically.