Craig McClanahan wrote:
The other thing to look at, besides total memory occupancy, is whether
caching stuff in the session reduces the amount of database access you
need on each request (especially stuff you have to reread because it
*wasn't* cached). Depending on the characteristics of your
application, this tradeoff could *substantially* improve the overall
performance of your application, and be well worth an investment in
additional memory.
Well, caching is a a good way to go, it does not have to be directly the
session, I once implemented a memory sensitive application cache for an
app, via weak referenced hashmaps and object timeouts.
There I dumped pretty much every thing into which was accessed
frequently (to avoid conflicts I mapped the data to the user).
That way I could reduce the session sizes tremendously and still had a
very fast access, because after a few minuts the cache basically ran
into a constant state between the needs of the garbage collector and the
accesses and was serving most of its data from the cache.
Nowadays I probably would not follow this approach anymore, most ORM
mappers now have very good caching systems so there is no need for
extensive caching on app level anymore in most normal cases.
Werner
