Issue #345 resolved

sessionfilter.!RamStorage saves data even if saveData is not called in beforeFinalize

Christian Wyglendowski
created an issue

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.

Comments (5)

  1. Anonymous

    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.

  2. Christian Wyglendowski reporter

    ''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.

  3. Log in to comment