On 2/20/07, Aaron Bannert <[EMAIL PROTECTED] > wrote:
On Sun, Feb 11, 2007 at 11:14:59AM -0500, Bill Erickson wrote: > I'm developing a Perl module for Apache2, and while I was testing keepalives > on Apache2 (prefork, 2.2.3, default Debian package), I noticed that requests > were being handled by different children, even though they were inside a > single keepalive session. > > 1. Is this the expected behavior? > 2. Is there any way to force apache to send all keepalive requests to the > same child process? Are you sure the client library you were using was actually using keepalives? With all of the current Apache MPM architectures, all keepalives requests will be handled by the same thread in the same process. Each time you make a new TCP/IP connection, however, it will be processed by a new thread/process.
Yep, I was wrong. There was something in my environment that was causing the connections to close. Testing elsewhere gives me the behavior I was expecting. (Long story, but I was getting worried there for a bit...)
Basically, I'm trying to leverage keepalives to allow for multiple requests > inside a single database transaction. For that, the client needs to be able > to communicate with the same child process throughout the transaction. I can't see how this will work. Since keepalive connections are not guaranteed to be supported by the server, and because the server can close off a keepalive connection at any time (see the spec for details), you can't assume that the entire multi-request transaction will be complete before the server stops processing. In other words, if your transaction requires 10 commands, you can't assume that the server will allow you to send all 10 corresponding HTTP requests, or even more than 1 per keepalive connection.
Let's say I can guarantee persistent connections (previous problems notwithstanding). I administer the server. I write the application. I know Apache well enough to know why a persistent connection will be severed. Regardless of whether my application is portable (not my concern right now), is this just off-the-wall crazy? :) Are there any other obvious gotchas I'm missing? An alternative might be to build up the transaction data in some server-side
session state, and then when all the data is accumulated you can make one transactional call to the database.
Thanks for the excellent feedback. -bill <http://open-ils.org>
