On Thu, Mar 20, 2008 at 10:35 AM, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> You definitely see this process serving more requests? Not sure why > the scoping is working that way for you. Maybe something is causing > it to wait until the connection is gone, and keep-alive is preventing > that from happening. > Absolutely... it's serving other requests. Requests to different users. 28886 Writing 9bb4a64cfb11fad62936ec32582b1c90 Wed Mar 19 13:14:53 2008 28886 Writing 9cb5700cbced993375aa1c03d1297e2c Wed Mar 19 13:16:31 2008 28886 Writing 9cb5700cbced993375aa1c03d1297e2c Wed Mar 19 13:16:32 2008 28886 Writing db87bde57bc9683fc8a4418f97b30e53 Wed Mar 19 13:17:59 2008 28886 Writing db87bde57bc9683fc8a4418f97b30e53 Wed Mar 19 13:18:01 2008 28886 Reading 9bb4a64cfb11fad62936ec32582b1c90 Wed Mar 19 13:18:24 2008 OLD SESSION READ: 9bb4a64cfb11fad62936ec32582b1c90 28886 Wed Mar 19 13:14:53 200 Something I just noticed... %session is global, so it never technically goes out of scope. Nor is it ever undefined, suggesting to me that it's only destroyed when it's overwritten... by the next non-js, non-image, request. But that's not what's happening in all cases... In some cases, it is being written immediately. In fact, it seems to only present itself on the first request after authentication, which points right back to a problem with my code. Also, it's Apache::Session that contains the methods for handling the tie-ing. It has no UNTIE method... only DESTROY, which suggests that if this were a bug, someone would have found it by now. >From Apache::Session perldoc: "When you untie() the session hash, or it passes out of scope, Session checks to see if anything has changed. If so, Session gains an exclusive lock and writes the session to the data store. It then releases any locks it has acquired." Why this would suddenly present itself after migration to new hardware is a bit of a mystery, and one I'm not terribly inclined to solve. Thanks for your help though, Rob
