Heap Memory

Memory-based session

One such hard limit is memory available, particularly in interpreted or man-aged code languages. Take a look at the following figure. Excess traffic can stress the memory system in several ways. First and foremost, every user has a session in the back-end of a web app. Assuming we use memory-based sessions (see Off-Heap Memory, Off-Host Memory), for an alternative to in-memory sessions, the session stays resident in memory for a certain length of time after the last request from that user. Every additional user means more memory.

Saving the memory

During that dead time, the session still occupies valuable memory. Every object we put into the session sits there in memory, tying up precious bytes that could be serving some other user.

When memory gets short, a large number of surprising things can happen. Probably the least offensive is throwing an out-of-memory exception at the user. If things are really bad, the logging system might not even be able to log the error. If no memory is available to create the log event, then nothing gets logged.

Session with little memory requirements

A supposedly recoverable low-memory situation will rapidly turn into a serious stability problem. Our best bet is to keep as little in the in memory session as possible.

For example, it’s a bad idea to keep an entire set of search results in the session for pagination. It’s better if we re-query the search engine for each new page of ...