In an ASP.NET Session object, what is the Entity Framework Object Context?

asp.net entity-framework httpcontext objectcontext session

Question

We have an Asp.NET Web Forms application with many layers. There is a class in the data layer calledDataAccess which effectsIDisposable It has a private property that contains an instance of our Entity Framework Object Context. The class contains a variety of public methods that return different collections of Entities, and when it is destroyed, it will also dispose of its object context.

We determined it would be a major positive to preserve the Object Context (or an instance of it) because of a number of issues we've been having.DataAccess ) in scope on the server longer. The idea of maintaining an instance in theHttpContext.Current.Items in order to have one instance every HTTP request, collection from these words.

What worries, conflicts, or challenges do you think might result from keeping an instance of our Object Context in theHttpContext.Current.Session object????

  • When a user's session terminates, I'm expecting that the Session object is finalized and set for trash collection, ensuring that the instance will be correctly disposed of.
  • The majority of default browser settings, I believe, will allow our program to establish its SessionId cookie without issue.
  • With respect to caching over time and the relatively low number of concurrent users, the quantity of data the Object Context will be handling is not large and won't be an issue for our adequate server hardware.

The numerous unit tests we now have won't be impacted by this, and it will be rather simple to install.

To provide instances, we'll be use AutoFac and a ServiceProvider class. When an instance of the ObjectContext is needed, code that looks like this will yield it:

private static Entities GetEntities(IContext context)
{
    if (HttpContext.Current == null)
    {
        return new Entities();
    }

    if (HttpContext.Current.Session[entitiesKeyString] == null)
    {
        HttpContext.Current.Session[entitiesKeyString] = new Entities();
    }

    return (Entities)HttpContext.Current.Session[entitiesKeyString];
}

Cheers.

1
4
3/5/2010 1:28:48 AM

Accepted Answer

Keeping anObjectContext Since the class is designed to encapsulate a unit-of-work pattern, where you load in some data (entities), alter them, commit your changes (which are recorded by the UOW), and then you're done with it, I wouldn't consider this an acceptable practice. UOW things are not made with longevity in mind or by design.

Nevertheless, if you know what's going on in the background, you may do this without triggering any significant calamities. If you want to do this, call read on please so that you are informed of the risks and the benefits of your decision.


I'm assuming that the Session object is finalised and set for garbage collection when a user's session expires, so the instance will be disposed properly.

Actually, this is false, or at least it seems to be based on the way it is written. None of the objects will be thrown away right away when the session ends or you log out. They will be finished/disposed of, but the trash collection decides when, and you have no influence over it. The main issue here is if you accidentally manually open a connection on theObjectContext , which won't be closed immediately — if you're not cautious, you may wind up leaking database connections, something that ordinary unit tests, integration tests, and live tests wouldn't catch.

The amount of data the Object Context will be dealing with is not enormous and will not pose a problem for our decent server hardware, with regards to caching over time and relatively few concurrent users.

Just bear in mind that there are no limits to the expansion. The context will only grow if a given user chooses to use your website for 12 hours nonstop, doing various inquiries throughout the day. AnObjectContext does not scavenge items that have been stored or tracked but have not been utilized in a long time, nor does it have its own internal "trash collection." The biggest issue that should be disturbing you is the fact that you lack control over the scenario. If you're certain that this won't be a problem based on your use cases, then great.


Thread safety is another problem.ObjectContext is thread unsafe. Session access is often serialized, thus until the completion of another request for the same session, the first request will stall waiting for its session state. However, if subsequent improvements are made, particularly the optimization of page-level read-only sessions, requests will no longer retain an exclusive lock, and you may encounter a number of race situations or re-entrancy issues.

The problem of multi-user concurrency is, of course, last but certainly not least. AnObjectContext till it is disposed of, stores its entities forever and ever. If a different user modifies the same things independentlyObjectContext , the original owner ofObjectContext will never learn about that modification. These stale data issues may be very frustrating to troubleshoot since you can actually see the query go to the database and return with new data, yet the problem still persists.ObjectContext will replace it with the outdated information already present in the cache. This, in my view, is perhaps the most important reason to steer clear of long-livedObjectContext Although you believe you have programmed it to get the most current data from the database, there are stillObjectContext will determine that it is more intelligent than you and give you the previous entity in its place.


Okay if you are aware of all of these problems and have taken action to lessen them. But I would want to know why you believe that a session-levelObjectContext such a fantastic idea? Making anObjectContext It really a fairly inexpensive procedure due to the caching of the information throughout the whole AppDomain. I'd venture a guess that either you're attempting to create complex stateful processes across several web pages, which would have much greater long-term effects than any immediate damage you may do by merely adding an annotation, or you're mistakenly under the assumption that it's costly.ObjectContext entering the meeting.

There aren't many good reasons to do this, so if you're going to do it anyhow, just be sure you're doing it for the proper reasons. However, as I previously said, it is unquestionably feasible, and your app won't crash as a consequence.


Please read the Overview of the ASP.NET session state documentation at the bottom if you are thinking of downvoting Update because "many requests on the same session might create thread-safety concerns." Serialization extends beyond simply the each person accesses of the session state; every request that obtains a session maintains an exclusive lock on the session, which is held until the end of the request as a whole. It is never feasible in the default setup for there to be two concurrent requests holding references to the same session-local instance of an object, with the exception of some of the optimizations I outlined above.ObjectContext .

Even so, I wouldn't keep anObjectContext For many of the reasons mentioned above, in the session state, but it is not a thread-safety concern until you make it one.

18
3/7/2010 1:25:48 AM

Popular Answer

ZZZ_tmp


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow