Ticket #345 (defect)
Opened 3 years ago
Last modified 3 years ago
sessionfilter.!RamStorage saves data even if saveData is not called in beforeFinalize
Status: closed (fixed)
| Reported by: | dowski | Assigned to: | rdelon |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.1-final |
| Component: | CherryPy code | Keywords: | |
| Cc: |
Using RamStorage, even if an exception occurs in an exposed method that updates a value in cherrypy.session, the session keeps the updated value despite the fact that saveData() is never called in beforeFinalize().
See the attached file for a reproduceable scenario. Refresh the page 5 times, you will get a traceback, then refresh again. The value is incremented.
The FileStorage backend behaves as one would expect: it does not update the session value if the exposed method raises an exception. Uncomment the config settings in the attached file to test it with file based sessions.
Attachments
Change History
10/13/05 00:31:54: Modified by dowski
- attachment sessionbugtest.py added.
10/13/05 00:32:41: Modified by dowski
- summary changed from sessionfilter.RamStorage saves data even if saveData is not called in beforeFinalize to sessionfilter.!RamStorage saves data even if saveData is not called in beforeFinalize.
10/13/05 10:45:43: Modified by rdelon
Well, there's 2 things here:
- first of all, should the session still get saved when an error happens or not ? I think it should not.
- however, the RAM backend is a bit special because the data gets changed directly in the main dictionnary ... We could change that by manually copying the data in a temporary dictionary and only copy it back to the main dictionary when the session is saved, but then we would lose the ability to use "explicit" locking and to just acquire/release the lock when we need it ...
What do other people think ?
Remi.
10/13/05 19:17:47: Modified by dowski
should the session still get saved when an error happens or not ? I think it should not.
I agree.
Ideally, at least the built-in session backends would have the same sort of behavior, but from your comments it sounds like that is not readily possible. If the saveData and locking behaviors are mutually exclusive, I guess it comes down to which one we want to keep consistent with the other backends.
If I were a heavy user of sessions, I would want the api level stuff to be consistent across backends. I imagine developers serious about sessions either use the file or db based backends in production. Maybe a caveat in the ram based session implementation would be forgiveable?
Maybe there is some way to have both that we haven't thought of yet.
10/21/05 07:22:37: Modified by rdelon
- status changed from new to closed.
- resolution set to fixed.
It will stay like this for now and I've documented this behavior in [742]
RamStorage sessionfilter bug example