On Wed, October 11, 2006 8:46 am, Bauer, Jay W wrote: > Yes there have been some trigger-happy, bug-bogus-marking going on, > but that happens. > > And yes, this stays alive without anything going on. And we have > tested your "other wrinkle" and that is how we have been able to end > the > persistent connections by making connections to a non-oracle-db > request > which will terminate the persistent connections. The only other way > has > been to restart apache. And I can redo the test with just one server > and one connection and explicitly terminate the persistent connection > by > making a new non-oracle-db request. Okay, so here's the thing... At what point in the process of normal web-server operations would you expect PHP to "notice" that the connection is stale and it should die? It's clear, to me, and to many others, that the problem here is not that it doesn't work -- Just that it "works" in a non-intuitive way for perfectly logical technical reasons. To clarify this, consider your one-process, one-user, one-hit test. Time 00:00 User asks for URL that accesses DB 00:01 PHP opens persistent connection 00:02 PHP returns HTML to user [It's probably not really 2 seconds, but let's just pretend.] At this juncture, Apache and PHP pretty much just go back to sleep, and don't do anything at all until something else comes along to wake them up. If the next thing to wake them up authenticates against the DB, and starts using the connections, then they are re-used, because they are already there, and there is no sense in tearing down a perfectly good "stale" connection if you're about to build another one. If the next thing to wake them up does NOT use the DB connection, the connection is noticed to be stale and killed off. This is how it works, as far as we can see from your testing. So there are several possible solutions here. PHP could set some kind of "timer" to wake itself up, check any outstanding persistent connections, and kill them off. This would need to be managed so that there is only one active "timer" and its wake-up time is extended as various events occur, since you wouldn't want it doing too much extra work that PHP is already doing. That would probably involve a great deal of inter-process communication and some significant overhead. The other option, cheap and easy, is to behave the way it does now: If somebody wakes PHP up, and it sees a stale connection, and it's not gonna use that stale connection, it kills it off. Now for MOST users, on MOST real-life scenarios, the cheap and easy solution is best. For those who have an unusual case, such as your dev server, a cron job to "heartbeat" a non-DB page every X minutes is a no-brainer, once one understands what's going on and why. You are certainly welcome to code and submit a patch to PHP to make it wake up and kill off stale connections, if you really think this is absolutely crucial... But if it has the kind of overhead I suspect it would have, it's not likely to be implemented. Or you could run a heartbeat cron job to a non-DB connection just a little bit longer than your connection time-out, and call the problem solved. NOTE: I am NOT an expert on PHP internals, and may be grossly incorrect about all this. I'm just giving my perception of your test results, based on how HTTP / Apache/ PHP generally work. PS I think this is how all the "persistent" connections operate... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
