quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (MODPYTHON-176) PSP.run() should not unlock session if it didn't create it.
Date Sat, 29 Jul 2006 12:26:14 GMT
     [ http://issues.apache.org/jira/browse/MODPYTHON-176?page=all ]

Graham Dumpleton resolved MODPYTHON-176.
----------------------------------------

    Fix Version/s: 3.3
       Resolution: Fixed

Fixed, but did not deal with issue of autosaving. That can be revisited later if it ever becomes
a problem.

> PSP.run() should not unlock session if it didn't create it.
> -----------------------------------------------------------
>
>                 Key: MODPYTHON-176
>                 URL: http://issues.apache.org/jira/browse/MODPYTHON-176
>             Project: mod_python
>          Issue Type: Improvement
>    Affects Versions: 3.2.8
>            Reporter: Graham Dumpleton
>         Assigned To: Graham Dumpleton
>            Priority: Minor
>             Fix For: 3.3
>
>
> When PSP.run() is exiting, it unlocks the session even if it had not created the session
object in the first place. In other words, it still unlocks the session if it was inherited
by using that already stored as req.session.
> By rights it should not unlock the session object when it is inherited from req.session
as that causes limitations when PSP objects are being used explicitly as a templating system
from publisher or other handlers. Specifically, it would prevent the handler which used the
PSP object making changes to the session object after PSP.run() has been called and then doing
a subsequent save of the session.
> That session locks should not perhaps be unlocked by PSP.run() was first mentioned in
MODPYTHON-38. Note that the session still gets unlocked, but by a cleanup handler registered
by the session object when it was first created.
> At the same time, it could be said that PSP.run() shouldn't call save on the session
automatically when the session object is inherited and that the save should be left up to
the handler making use of the PSP object in these situations. Existing use of the PSP objects
would need to be evaluated to determine if disabling autosave would cause issues for existing
code if such a change were to be made for when session object inherited. A better option may
be to add an additional argument run PSP.run() called autosave which defaults to True to preserve
existing behaviour, but allow explicit users of PSP objects to change the behaviour if required.
This all gets a bit complicated when error pages come into the picture though, so more thought
needed on this latter point of autosave.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message