Dbcontext, который является потокобезопасным? | VPROS.ru

Dbcontext, который является потокобезопасным?

Мне было интересно, если DbContext класс является потокобезопасным, я предполагаю, что это не так, как я в настоящее время выполнения потоков параллельно, что доступ к DbContext в мое приложение, и я получаю множество исключений замок и другие вещи, которые выглядят как они могут быть нить отношение.

До недавнего времени я не получаю никаких ошибок…но я до последнего не было доступа к DbContext в нити.

Если я прав, что бы народу предложить в качестве решения?

One Reply to “Dbcontext, который является потокобезопасным?”

  1. Отредактировано – старый ответ ниже.

    Я теперь всегда используйте этот шаблон с dbcontext, который:

    using(var db = new LogDbContext()) {     // Perform work then get rid of the thing } 

    Мой подход один по запросу резьба означало кэшированных объектов в dbcontext, который будет придерживаться вокруг и устарели даже в то время как другие dbcontext в случаях писали новые значения фактической базы данных. Это создаст какие-то странные вопросы, например, один запрос выполняет и вставьте следующий запрос для списка в другой поток, что было в кэше, черствый список данных для этого запроса.

    Существуют подходы, которые делают ниже работы и даже повысить производительность многих-читает/несколько-пишет стиль приложения, но они берут больше конструкции и стратегии, чем проще гораздо выше шаблон.

    Обновление

    Я также использовать полезный вспомогательный метод для методов библиотеки, как ведение журнала звонков. Вот вспомогательный метод:

        public static void Using(Db db, Action<Db> action)     {         if (db == null)         {             using (db = new Db())             {                 action(db);             }         }         else         {             action(db);         }     } 

    С этим я могу легко написать код, который принимает необязательный существующие на dbcontext, или создает один внутри с помощью контекста, в зависимости от того, как это случается, называется.

    Например, при работе с dbcontext, который я мог бы загрузить некоторые данные, войти некоторые данные, а затем сохранить эти данные – лучше делать это все с той же dbcontext, который с точки зрения производительности. С другой стороны, я может тоже хочу что-нибудь журнала в ответ на простое действие, и ни нагрузки, ни писать любые другие данные. Используя вышеописанный способ я могу иметь только один способ ведения журнала работ, хотите ли вы работать внутри существующей dbcontext или нет:

    public void WriteLine(string line, Db _db = null) {     Db.Using(_db, db => {         db.LogLines.Add(new LogLine(line));         db.SaveChanges();     }); } 

    Теперь при вызове этого метода можно назвать внутри или за пределами существующей dbcontext и еще вести себя правильно, вместо того, 2 есть 2 версии этого и всех других удобство лесозаготовки метод или иную утилиту, способ у меня есть, и вместо того, чтобы знать и планировать контексте каждого вызова, что никогда не будет сделано для них или их абоненты. В основном это возвращает мне одно из преимуществ указанных ниже стратегии threadstatic, где я не придется беспокоиться о том, когда был открыт ровно дБ коммунальных звонки, что стоит волноваться по этому поводу.

    Старый ответ

    Я обычно ручки потокобезопасность с EF dbcontext и вот так:

    public class LogDbContext : DbContext {     . . .      [ThreadStatic]     protected static LogDbContext current;      public static LogDbContext Current()     {         if (current == null)             current = new LogDbContext();          return current;     }      . . . } 

    С этим в место, которое я могу получить, что dbcontext по этой теме вот так:

    var db = LogDbContext.Current(); 

    Важно заметить, что с каждым dbcontext, который держит в своем локальном кэше, каждый поток будет иметь свой собственный отдельный кэш объектов, которые можно ввести какой-то сумасшедший поведение, если Вы не готовы к этому. Однако, создавая новые объекты dbcontext может быть дорогим, и такой подход минимизирует затраты.

Comments are closed.