Right. There's not only the question about the session lifetime.
"Where do happen the session modifications" seems a non-trivial
question with large applications. I've tried a layer architecture.
There's exactly one layer knowing of [and modifying] the session. But
that architecture is broken in a
i was using the antipattern of one session forever (huge non-web-app).
the pros are - caching; the cons are longer:
- usual cache stuff - changes to the obj in the DB won't come unless
i expire it
- any changes to anything keep accumulating and hence get flushed()
at unexpected times. in gene
