Session Management - Architecting State Data

Most modern business applications have some state or context.  This model can be easy to implement in a stand-alone application.  However, multi-user applications like web sites can be a challenge when you consider session management.  While security is often a hot topic, tracking data correctly can be an issue to itself.  We need to build our architecture to handle the ways we pass around such data. Session Management Is More Than Global Values One of the "rookie mistakes" of session management is the use of it as a sort of global bucket.  It is not uncommon to see all manner of objects and values shoved into the session.  While this approach makes it easier to pass values, it is not secure and wastes resources.  Therefore, it is important to think through what values should be stored.  As with manner, other design decisions, when in doubt, leave it out (of the session).  There should be a strong reason for each item you store at the user or application level. Now Vs. Later Comparison While we just said it makes sense to keep the session small, there is also caching to take into account.  There are valid reasons to store values in the session rather than make multiple calls to retrieve them.  Thus, this is not an area of architecture that is always cut and dry.  There are application-specific requirements that will come into play.  Keep in mind the trade-off of memory to cache data and network traffic to load it. Design, Not Implementation We can always kick decisions like this down the road.  The implementation team can make choices related to caching data and session management.  However, that can lead to ad-hoc storage and other challenging to maintain situations.  It is worth the time and effort to architect your session situation.  Future developers and maintainers will thank you,

There are no comments yet.

Please log in to write the first comment.