On Sun, Dec 13, 2009 at 8:16 PM, Graham Dumpleton <
[email protected]> wrote:

>
> 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.
>
>
Thanks for the overview on that.  You are correct, we're looking for cross
thread, cross process, cross machine session management.  But we don't want
the locks to create a performance issue either.

--
I'm considering using the PostgreSQL advisory locking functionality to
1. get a lock on that session id at the beginning of the request
2. read the session data
3. update the session data
4. release the lock
5. finally process the guts of the page and output content

In this way, we keep the locking time to an absolute minimum at the start of
the request.  However, some requests will need to updated the session data
using data calculated during that request (login pages are an example of
that).  To handle that, we could either (a) repeat the above process at the
time the session data needs updated, or (b) instruct that specific request
to hold the lock longer until released manually later, or automatically at
the end of the request.

In our web apps, there are very few "pages" which actually update the
session after the very beginning of the request.  Routine updates consist of
"hit count", and "access time" for authentication purposes.

BTW, I'd like to use memcached, but am not clear on what
locking possibilities it has.

Anyone see any holes in that logic?

Thanks for taking the time...
Jason Garber

--

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.


Reply via email to