Re^2: Apache::Session problems under high load

First of all, you really need to tell us a specific set of Apache::Session::Flex args or a specific subclass that you want to use. The behavior is different for different ones. For Apache::Session::File, you need to pass the "Transaction => 1" argument, as borisz said, to make it do exclusive locking the way you are imagining it. With Apache::Session::MySQL, you do not need that, although it shouldn't hurt anything.

The other thing is that you should make sure your application truly needs this. Hardly any web apps do. Typical data to store in a session is stuff like a user ID or part of a multi-page form. These are things where "last save wins" is just fine. If you're storing things where you really need exclusive locking, you should probably consider putting them in a database instead.

Comment on Re^2: Apache::Session problems under high load

Replies are listed 'Best First'.
Re^3: Apache::Session problems under high load by xpatiate (Initiate) on Oct 28, 2004 at 05:58 UTC
Thanks. 'Last save wins' would be fine as long as we could guarantee that the last save was actually the last request the user made. The fundamental problem we're having is that intermittently, under relatively heavy load, sometimes the app just does not get the session data written on the previous request. I came across a situation recently where opening a page in a javascript window set up a kind of race condition with session data ... the request still being processed in the parent window seemed to prevent the request in the child from writing to the session. So we hypothesised that this might be what is happening (especially as Apache::SessionManager doesn't untie the session until the very end of the request, after content has been sent back to the client) and investigated the locking process to see if it was possible, because we thought locking should prevent that. The most frustrating aspect to this session problem is that it affects the real users of the system much more than it does us the developers. We've only encountered the error once in testing, whereas they're getting it quite frequently. We're geographically very distant from the server whereas the users are quite close, so this sort of led me down the path of speculation that it's like a race condition between requests (because theirs would get back to the server much faster than ours). We've disabled javascript and redirects that send further content and this has improved things, but not fixed them. If we can't solve it, maybe we do need to look at storing the session data some other way.	[reply]
Re^4: Apache::Session problems under high load by perrin (Chancellor) on Oct 28, 2004 at 19:02 UTC
Apache::Session can do the kind of exclusive locking you are after. If you're not using the MySQL locking, make sure you're passing "Transaction => 1". However, it would be better to move this kind of work to direct database actions so that you can get better control over the concurrency and locking behavior. Sessions are good for things that are mostly read-only and don't change often (e.g. user's name). They're not so great for things that need carefully controlled locking behavior. Part of the issue is that when you use exclusive locking, a person opening a second window on your site will not get any content until the first window completes sending to the browser. That's the nature of exclusive locks.	[reply]
Re^5: Apache::Session problems under high load by Anonymous Monk on Nov 01, 2004 at 08:16 UTC
Thank you for this; we will now go away and try to replicate the process with Transaction=>1 for file-based locking. So far, we have never seen proper locking under MySQL but we should try the above argument with File. Best regards and thankyou for your thoughts on this, it has been a stress for us... I will report back with the outcomes, Kind regards, Craig.	[reply]
Re^6: Apache::Session problems under high load by Anonymous Monk on Nov 02, 2004 at 15:24 UTC
Re^4: Apache::Session problems under high load by Anonymous Monk on Oct 28, 2004 at 08:36 UTC
You problem is one of design (you've designed a race codition). Session managment is not a magic cure, and neither is testing. Rework your logic.	[reply]