[mod_python] session and psp (Was This is just friggin' weird...)

Jim Gallacher jg.lists at sympatico.ca
Fri Jun 24 11:52:22 EDT 2005

Jim Gallacher wrote:
> Graham Dumpleton wrote:
>> On 24/06/2005, at 10:36 PM, Jim Gallacher wrote:
>>> And misses these issues:
>>> 3. Should the session automatically be saved in psp run()?
>>>    Yes: - it's the current behavoiur
>>>         - using sessions with psp pages is transparent
>>>         - the user does not need to remember to do this
>>>    No:  - the code monkey has less control over their application
>>>         - ?
>>>    Maybe we just need a attribute in the session to enable/disable 
>>> saving? Default would be to save the session.
>>> 4. Should the session be unlocked in psp run()?
>>>    Yes: - it's the current behavoiur
>>>    No:  - since we are now passing around the session instance with 
>>> the request, the session will be unlocked when the request is completed.
>> Am not suggesting that the behaviour of PSP object be changed for 
>> where it
>> is triggered from mod_python.psp, that would stay the same to ensure
>> compatibility. Am thinking more about the situation where someone is
>> using PSP object explicitly from a publisher handler to render HTML.
>> As it stands at the moment, if publisher code created a session object
>> and the PSP page accesses "session", you will get a deadlock. This means
>> that in practice no one is doing this at the moment. Thus, one could 
>> have:
>>         session = None
>>         session_created = False
>>         if "session" in code.co_names:
>>             if not hasattr(req,"session") or req.session is None:
>>                 session_created = True
>>             session = req.get_session()
>>         ....
>>                 if session is not None and session_created:
>>                     session.save()
>>         finally:
>>             if session is not None and session_created:
>>                     session.unlock()
>> In other words, if created by PSP object, still save it and unlock it.
>> If created externally, assume that code that triggered creation of it
>> will also ensure it is saved as well and unlock if appropriate.
> Makes sense. There is still a problem where a user is keeping a 
> reference to their session in the request object but using a name other 
> than session as the key. eg. req.sess = Session.Session(). Oops, 
> deadlock. No easy solution to that other than documenting it.
>> Only problem with this is that req.get_session() hides the real session
>> object and there isn't a way to tell if it has already been created.
>> Ie., above assumes that "session" attribute stores the Session object
>> instance or provides access to it which doesn't current occur.
>> Thus, you might want to consider adding to request_rec_mbrs a hook for
>> getting access to the session object so one can tell if it has already 
>> been
>> created, or have a member function that can be called to query whether
>> session exists yet.
> I had considered using getreq_recmbr/setreq_recmbr for managing sessions 
> but rejected it because of concern about breaking existing user code. It 
> may seem obvious that people would only save a session instance in 
> something called req.session, but I'm never suprised by the strange 
> things people do. You just know that someone is using req.session for 
> something else, like the session id, or their mother's maiden name.
> I do see a need for a way to test of the existence of a session with 
> something like req.session_exists(). Go too far done that road though 
> and we end up with get_session, set_sesssion and session_exists methods, 
> which is becoming rather ugly. What I really need to do is put together 
> a document which outlines the goals for the new session management 
> mechanism, and throw it out there for a wider discussion. The code to 
> handle all this is pretty simple, so it won't really delay the release 
> of 3.2 if changes are required.

After thinking about this for another 10 minutes, I'm starting to think 
getreq_recmbr/setreq_recmbr might be the better way. The psp code could 
check if req.session is a subclass of BaseSession to make sure there are 
no unintended consequences. And people really wouldn't save their 
mother's maiden name in req.session, right?  RIGHT??? ;)


More information about the Mod_python mailing list