2009/12/14 Damjan <[email protected]>: > > > On Dec 13, 12:30 am, Jason Garber <[email protected]> wrote: >> Hello, >> >> This email is about the need to protect sessions from getting run over by >> concurrent request by the same user. Here is a couple notes on the >> requirements. >> >> 1. Python 3: running mod_wsgi on Apache and Python 3.1 >> 2. Load Balancing: multiple servers are serving one application. >> 3. Daemon Processes: would like to employ more than one daemon process per >> application. >> 4. Performance: would like the solution not to adversely >> impact performance of the web application. >> >> So essentially what I am looking for is distributed session storage, where >> there are no loopholes of one request invalidating another's session data >> due to them running concurrently. > > Beaker + memcached backend?
But does it have cross process/cross system session locking for life of request with session open? One of this things that mod_python session objects did was to lock out any parallel requests by same user. This prevented unsynchronised updates to session data in session database at same time. I don't recollect see anything similar in any of the other Python web frameworks or toolkits like that. What other session mechanisms generally allow is for user request 1 to read session object, then user request 2 (both same actual user), to also read session object. Data for request 1 would then be written, and then that for request 2. Thus any data changed in request 1 would be lost. In mod_python, the locking of the session object for user request 2 would be blocked because user request 1 hadn't completed. This would be the case even if the requests were being handled by a different process. Thus, no way user request 2 could even get a copy of session object and when it does it will always be the result of that from user request 1. In other words, session object access is always serialised, something that many session locking mechanisms don't ensure. The way the mod_python session locking worked was to create in the Apache parent process a pool of cross process session locks. This was only about 3 or 4 locks. When a session was to be locked for a particular request, it would actually lock one of the global cross process session locks. Which lock was used was from memory based on some sort of mod on hash value calculated from session ID. What this meant was that many session IDs could actually map to a specific lock and so by acquiring the cross process lock you actually locked out many more users than just the one for the request you were handling. I don't think people realised this fact. End result was that the session locking could be a real bottleneck especially where requests were longer than average. Frankly surprised people didn't have a lot more problems with it than they did. Now, although mod_python tried to serialise session access, that only worked where all requests being handled on same Apache instance. No such serialisation occurred if you were load balancing across multiple Apache instances on different machines. Doing the latter would also have necessitated using a session database that wasn't local to a machine. >From original post, seems they want this sort of serialised session access and update across multiple processes and machines. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
