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
Type: Improvement

Versions: 3.2.8
Reporter: Graham Dumpleton
Priority: Minor


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 expli
citly as a templating system from publisher or other handlers. Specifically,
 it would prevent the handl
er 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 men
tioned 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 sav
e should be left up to the handler making use of the PSP object in these sit
uations. Existing use of th
e 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 wh
en session object inherited. A better option may be to add an additional arg
ument run PSP.run() called
autosave which defaults to True to preserve existing behaviour, but allow ex
plicit users of PSP objects to change the behaviour if required. This all ge
ts a bit complicated when error pages come into the picture though, so more 
thought needed on this latt
er point of autosave.

[ Post a follow-up to this message ]