StructureMap warns of caution when injecting in a session - why?

Question

In the StructureMap documentation for the life cycle, they state that one option to define the scope is HttpSession and that it: "cache instances in HttpContext.Session should be used with caution."

I do not know what to be careful, and my google-fu fails.

In this case, we have some expensive web service calls that we would like to cache. Some of them are stateless, but some of them are tied to a specific user.

When are we bad, mischievous people, if we introduce into the scope of the session? What do we need to protect?

Answer 1

I will describe the problems with this using an extreme example: caching a work item unit (e.g. LINQ to SQL DataContext , Entity Framework ObjectContext or DbContext or NHibernate ISession )):

Memory

A unit of work objects is often held on a large number of objects. Putting a session object in HttpSession means that it will work as long as the session will work, and with it all objects that are in the cache. Even if the user returns after 20 minutes, you will have this memory pressure on your application. This can (and with significant load) lead to memory exceptions.

Data becomes obsolete

Since the unit of work of the object caches all the objects that it loaded from the database, this data becomes quite outdated. When the data is changed by another user, the cached data will not be updated by default, and you may experience strange behavior when one user sees some data, but the other user sees other data. Refreshing the page will not work because you cached data throughout the session. Only closing the browser will work (sometimes).

Serialization

When you scale your web server (which means you are adding more servers), session information must be transferred from one server to another. You will have to use the cache outside the process (e.g. MemCache or SQL Server). A work item unit is complex or impossible to serialize and deserialize, which means you cannot scale if you want or need.

Summary

The example is extreme because you should never use a lifestyle in a work session on a work template. But he still quite clearly describes the problem. The lifestyle session style increases the memory capacity of your application, since the service is supported for a very long time. If you use such a service to cache data, it may become obsolete (although the cache may just be what you need to improve performance). Although DTOs are often easily serialized, this does not work for any service you register. This means that you cannot scale, since serializable session objects are necessary for scaling.

Therefore, instead of using a lifestyle in a session per session, try creating non-stateless services so that they can be registered as single. Any user data that they need can be requested from an HTTP session.