Hi Richard On Thu, 2008-11-20 at 09:28 +0000, Richard Jones wrote: > Ron Savage wrote: > > Hi Richard > > > > One thing to investigate: > > > > http://rt.cpan.org/Public/Bug/Display.html?id=17299 > > > > See the comment I added on Mon Oct 27 01:10:00 2008. > > > > Hi Ron, > > Yes, lots of info there about unreliable flushing. What happened to > cause this? Those reports were initially filed with the change from 3.95 > to 4.x nearly 3 years ago. It's still a feature in 4.20. It's > frustrating to see a major component like session handling suddenly > start misbehaving and not being able to track down the cause.
It's frustraing not being able to pinpont the problem. If I said it was invariably user code bugs, there'd be an uproar, and - even worse - I can't quite justify such a claim :-). Of course, not being able to reproduce the problem makes it very hard to attack. And I don't have any paid work at the moment, so I have to time to work on this problem, but what exactly can I do? As for the comment I refer to above, ok, let's say I can produce a problem, then the question is: Is it really the same problem everyone is having? How can I tell? So, yes, all in all, very frustrating. > If you're passing sid's in your form you're presumably not using > cookies, whereas I do, so that might suggest the problem is not related > to the manner in which the session id is passed. Correct. I've never used cookies. However, a new app I'm writing has a lot of Ajax in it, and forcing the sid into the post data is beginning to bug me, so I'm close to switching to cookies. Er, I assume Ajax triggers sending a cookie (client to server), but I don't recall ever reading that. Any ideas? > I did some tests with a barebones setup, and though not conclusive I > found that if I used $dbh directly for the authen and session configs > the session was created/updated, but if I used $self->dbh it was not. > But I can't reproduce that in my current app, so not sure how relevant > it is. For now I've put a call to session->flush in teardown and all > seems OK, though not tested under mod_perl yet. Your reference to $self->dbh is interesting. Does that mean you are using CGI::Application::Plugin::DBH? I've never used that. Unfortunately that add another complexity into the mix. How can we be sure that module does not contribute to the fail-to-flush problem? This, as always, comes back to the problem of not being able to trigger the condition at will. Without that, any proposed solution can be no more that theoretical, since a proposal which does not reveal the problem can't claim to have solved it, can it? -- Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
