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

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.

Regards,
Jim