.NET Entity Framework и транзакции
==================================

 Будучи новичком в Entity Framework, я действительно застрял в том, как поступить с этим набором проблем. В проекте, над которым я сейчас работаю, весь сайт тесно интегрирован с моделью EF. Сначала доступ к контексту EF контролировался с помощью загрузчика Dependency Injection. По оперативным причинам мы не смогли использовать библиотеку DI. Я удалил это и использовал модель отдельных экземпляров объекта контекста, где это необходимо. Я начал получать следующее исключение: 

>  Тип «XXX» был отображен более одного раза. 
> 
> 

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

>  Новая транзакция не разрешена, поскольку в сеансе запущены другие потоки. 
> 
>  Операция транзакции не может быть выполнена, потому что есть ожидающие запросы, работающие над этой транзакцией. 
> 
>  ExecuteReader требует, чтобы команда имела транзакцию, когда назначенное команде соединение находится в ожидающей локальной транзакции. Свойство Transaction команды не было инициализировано. 
> 
> 

 Последнее из этих исключений произошло при операции загрузки. Я не пытался сохранить состояние контекста обратно в БД в потоке, который не удался. Однако был другой поток, выполняющий такую операцию. 

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

 Я предполагаю, что мой первый вопрос, должна ли модель EF использоваться из одного статического экземпляра? Кроме того, возможно ли устранить необходимость транзакций в EF? Я пытался использовать объект `TransactionScope` без успеха ... 

 Честно говоря, я застрял здесь и не могу понять, почему (что должно быть) довольно простые операции вызывают такую проблему ... 

 Создание глобального `ObjectContext` в веб-приложении очень плохо. Класс `ObjectContext` не является потокобезопасным. Он построен вокруг концепции [единицы работы,](http://martinfowler.com/eaaCatalog/unitOfWork.html) и это означает, что вы используете ее для управления одним вариантом использования: таким образом, для бизнес-транзакции. Он предназначен для обработки одного запроса. 

 Исключение возникает из-за того, что для каждого запроса вы создаете новую транзакцию, но пытаетесь использовать тот же `ObjectContext` . Вам повезло, что `ObjectContext` обнаруживает это и выдает исключение, потому что теперь вы узнали, что это не будет работать. 

 Пожалуйста, подумайте об этом, почему это не может работать. `ObjectContext` содержит локальный кеш сущностей в вашей базе данных. Это позволяет вам сделать кучу изменений и, наконец, отправить эти изменения в базу данных. При использовании одного статического `ObjectContext` , когда несколько пользователей вызывают `SaveChanges` для этого объекта, как он должен знать, что именно должно быть зафиксировано, а что нет? Поскольку он не знает, он сохранит все изменения, но в этот момент другой пользователь все еще может вносить изменения. Когда вам повезет, EF или ваша база данных потерпит неудачу, потому что сущности находятся в недопустимом состоянии. Если вам не повезло, объекты в недопустимом состоянии успешно сохранены в базе данных, и через несколько недель вы можете обнаружить, что ваша база данных полна дерьма. Решением вашей проблемы является [создание хотя бы одного `ObjectContext` каждого запроса](https://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why) . Хотя теоретически вы можете кэшировать контекст объекта в пользовательском сеансе, это также плохая идея, поскольку `ObjectContext` обычно будет жить слишком долго и содержать устаревшие данные (поскольку его внутренний кэш не будет автоматически обновляться). 

 **ОБНОВЛЕНИЕ** : 

 Также обратите внимание, что наличие одного `ObjectContext` на поток так же плохо, как наличие одного экземпляра для всего веб-приложения. ASP.NET использует пул потоков, что означает, что в течение жизненного цикла веб-приложения будет создано ограниченное количество потоков. По сути, это означает, что эти экземпляры `ObjectContext` в этом случае будут продолжать существовать в течение всего жизненного цикла приложения, вызывая те же проблемы со стабильностью данных. 

 Вы можете подумать, что наличие одного DbContext для каждого потока на самом деле является потокобезопасным, но обычно это не так, поскольку ASP.NET имеет асинхронную модель, которая позволяет завершать запросы в другом потоке, отличном от того, где он был запущен (и последние версии MVC и Web API даже позволяют произвольному количеству потоков обрабатывать один запрос в последовательном порядке). Это означает, что поток, который запустил запрос и создал `ObjectContext` может стать доступным для обработки другого запроса задолго до того, как этот начальный запрос завершится. Однако объекты, используемые в этом запросе (например, веб-страница, контроллер или любой бизнес-класс), могут по-прежнему ссылаться на этот `ObjectContext` . Поскольку новый веб-запрос выполняется в том же потоке, он получит тот же экземпляр `ObjectContext` что и старый запрос. Это снова вызывает состояние гонки в вашем приложении и вызывает те же проблемы безопасности потоков, что и один глобальный экземпляр `ObjectContext` .