If the session object comes from a `store` object that is used by the request handler, we have the same problem.
Currently DB access from the session object (loading, renewing timestamp) is run before the request handler, so that hasn't been a problem. There are actually 2 cases to consider:
- Session data is independent from request handler's logic: flash message. In this case we want to store/remove session data regardless of whether changes from the request handler's are persisted or not.
- Session data is part of the request handler's logic: temporary data of multi-step registration, session-wide options that are applied on login... In this case we want changes to session data to be persisted if and only if changes from the request handler's are persisted.
Therefore the interface should be flexible enough to be part of another transaction (e.g. taking a `store` parameter), or starting/ending a transaction of its own.