|
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??? ;) Regards, Jim
|