I'm facing similar "problems". I have heavily modified the Mod_Python Session.py code first to run on mod_wsgi.
I have a system which is basically a web based os, with desktop in a browser. It was based on Mod_Python and with a fake interface to mod_wsgi it now is starting to work on top of that. It is basically a version of the mod_python package which builds a request object and calls "handler(Req)". Session, Cookies and some other stuff is working (like register_cleanup). For session storage I use SQLAlchemy (Excelent stuff look into it !!, In my case with Mysql, would work on top of any DB2 adapter, sure with Postgres). I'm thinking of doing the session locking on DB level. Since I'm working on Sessions for mod_wsgi and have modified it to store in MySQL or SQLAlchemy I might be able to help with a solution on that part. As it seems my system has what you want (and more like, webdav, caldav, email, exchange sync, licensing, user management, customer management). But it is way from beta version. Although the core and the webdesktop are going into production soon, many frontents have to be made. anyway call if i can help Martijn On Dec 16, 2009, at 2:31 AM, Graham Dumpleton wrote: > 2009/12/16 Damjan <[email protected]>: >>>> Beaker + memcached backend? >>> >>> But does it have cross process/cross system session locking for life >>> of request with session open? >> >> You mean like, >> - reading the session from mc, >> - changing something >> - saving a new copy to mc >> and if this happens concurently? >> >> From what I see in the code Beaker should support that, but maybe a >> clarification from the author would be needed. > > From what I see in the code I don't believe it does, or at least that > isn't the intent. Quoting code: > > def load(self): > "Loads the data from this session from persistent storage" > ... > > self.namespace.acquire_read_lock() > > try: > ... > > finally: > self.namespace.release_read_lock() > if timed_out: > self.invalidate() > > Note how it releases the only lock it got when reading session. > > Anyway, that is the default behaviour at least. It means no lock is > held for whole period of request that the session is being used and > possibly modified then written. > > To have it held for period of whole request, you need to lock it > explicitly. However, the comments in code for doing that are saying > that those functions should be removed as a TODO item. > > # TODO: I think both these methods should be removed. They're from > # the original mod_python code i was ripping off but they really > # have no use here. > def lock(self): > """Locks this session against other processes/threads. This is > automatic when load/save is called. > > ***use with caution*** and always with a corresponding 'unlock' > inside a "finally:" block, as a stray lock typically cannot be > unlocked without shutting down the whole application. > > """ > self.namespace.acquire_write_lock() > > def unlock(self): > """Unlocks this session against other processes/threads. This > is automatic when load/save is called. > > ***use with caution*** and always within a "finally:" block, as > a stray lock typically cannot be unlocked without shutting down > the whole application. > > """ > self.namespace.release_write_lock() > > So, the intention seems to be to not support the ability to have > locking be for life of request which needs to be able to update > session data, even though lock()/unlock() method allow for that at > present. > > Anyway, who actually reads code/documentation properly to know they > would have to call lock() explicitly to get what was default behaviour > of mod_python. > > 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. > > -- 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.
