1

I have a .Net Mvc projekt where i have a problem with my Databasecontext. More specific with update/saveChanges. When i am debugging the code with a debug point in the method(below) it seams to work but not without a debug point. I can´t understand why? Somehow the SaveChanges doesn't detect the changes to entity. 

var user = DatabaseContext.Users.Single(u => u.Id == userId && u.Newsdesk.Id == newsdeskId);
user.Newsdesk = null;
DatabaseContext.Update(user);
DatabaseContext.SaveChanges();

My update method in DatabaseContext looks like this:

public T Update<T>(T entity) where T : class
    {
        var set = Set<T>().Attach(entity);
        Entry(entity).State = EntityState.Modified;
        return set;
    }

If someone could point me in the right direction i would be very grateful

bassen
  • 191
  • 3
  • 10

1 Answers1

2

Quickly in and quickly out (that's what Gandalf said in one of the movies... :) I think).

By that I mean that if some godly observer were sitting inside the CPU looking at your app, what they should see is that your app runs the following sequence

{ connect, create context, make changes, commit them, destroy context, disconnect }

in a number of tens of milliseconds for (almost) each web request it receives.

Are you actually creating a context (entity container + unit of work) that exists throughout the app globally ?

I would recommend a more classical and not-so-dbconnection-friendly approach (not to mention transactionally-sanitized):

using (var context = DataContextHelper.CreateContext()) {
    var user = DataContextHelper.QueryAndSingleByLambdaBasedOnContext(
        context,
        u => u.Id == userId && u.Newsdesk.Id == newsdeskId
    );
    if (null == user)
       // complain somehow (by exception or special return value)
    user.Newsdesk = null;

    // don't mark it anymore, in the straight-forward, good'ol way
    // user will already have been marked 
    //DatabaseContext.Update(user);

    context.SaveChanges();
}

It is generally bad (especially if you're not careful) to somehow host a globally accessible context, that more than one thread can use concurrently.

I'm not talking about concurrency hazards while accessing some property. I'm talking about the big picture (maybe another request read the user and marked it as "not being modified" somewhere between your Update and the SaveChanges).

Event if that's not the case, you shouldn't worry about concurrent connections to the db. Concurrent access to the context is much harder to manage.

Eduard Dumitru
  • 3,242
  • 17
  • 31
  • Thanks for the fast response. The database context is created in the constructor of the controller. Is that a bad way of working with db context? – bassen Mar 01 '13 at 14:55
  • It might be or not. I don't want to hurt the idiosyncrasies of many experienced members and that's why I'm not saying **YES**. But in general the answer is: **yes**! Especially if you don't know what you're doing and have a wide and deep understanding of EF and .NET. Try to "stay connected to the db" as little time as possible. Create yourself a little _business logic_ container class where you operate changes to the database (and also to the reads). Make it so as that no other part of your app mentions the word **context** (as much as possible). Through this change you might solve the problem – Eduard Dumitru Mar 01 '13 at 15:08
  • Thanks for the help Eduard! Your answear was of great help to me. Now i have to decide if it is worth to refactor the implementation of the databasecontext. For the time being i found a solution to my problem here. http://stackoverflow.com/questions/6420976/setting-a-foreign-key-to-null-when-using-entity-framework-code-first – bassen Mar 04 '13 at 14:56