1

Я использую Entity Framework 5 Code Во-первых, я использую репозиторий и единицу рабочего шаблона и имею свой домен модели, репозитории и уровень обслуживания, работающие нормально в приложении MVC, работающем в облачной службе Windows Azure. Я использую Unity для IoC и при необходимости внедряю репозитории, контроллеры и классы обслуживания и использую пожизненный ресурс для каждого запроса. Он отлично работает.«Ошибка основного провайдера при открытии» Ошибка при использовании кода EF5 Сначала с Unity IoC в роли Azure Worker против SQL Azure

Однако, когда я использую те же библиотеки классов/классов для домена, репозитория и Eb5 DbContext, в роли рабочего Azure, указывая на ту же базу данных SQL Azure, что и приложение MVC, я получаю нечетные ошибки, которые я не вижу из приложения MVC. Обратите внимание, что на данный момент я просто читаю (выбираю), никаких транзакций обновления. Приведенное ниже сообщение об ошибке означает, что он не смог открыть соединение.

В роли работника у меня есть статический класс bootstrapper для создания контейнера и регистрации всех его сервисов. В роли рабочего роли я должен выполнить некоторую работу, поэтому я вызываю загрузчик для регистрации служб, а затем разрешаю пару из них использовать сразу. Этим службам вводятся репозитории, которые, в свою очередь, вводятся в мой DbContext, все они созданы контейнером IoC. Для DbContext я использую HierarchicalLifeTimeManager Unity в контейнере IoC.

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

The underlying provider failed on Open. at System.Data.EntityClient.EntityConnection.OpenStoreConnectionIf(Boolean openCondition, DbConnection storeConnectionToOpen, DbConnection originalConnection, String exceptionCode, String attemptedOperation, Boolean& closeStoreConnectionOnFailure) 
    at System.Data.EntityClient.EntityConnection.Open() 
    at System.Data.Objects.ObjectContext.EnsureConnection() 
    at System.Data.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption) 
    at System.Data.Objects.ObjectQuery`1.System.Collections.Generic.IEnumerable<T>.GetEnumerator() 
    at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) 
    at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) 
    at MyApp.Persistence.EF.RepositoryBase`1.Find(Expression`1 where, Expression`1[] includeProperties) 

Это точно такой же вызов метода работает отлично из приложения MVC. Я думаю, что есть что-то не так с объемом DbContext в рабочей роли, возможно, связано с временем жизни в IoC, но это всего лишь гипотеза.

Кто-нибудь может понять, что может послужить причиной этого исключения? Любой, кто использует роли EF, IoC, Repos/UoW и Azure Worker? Предложения?

+0

Возможно, это связано с тем, что EF не нашел вашу строку подключения. Я считаю, что Azure иногда использует различные механизмы настройки, чем обычные web.config или app.config, поэтому это может быть связано с этим. Кроме того, лучше всего использовать тег entity-framework при отправке вопросов EF. –

+0

@ArthurVickers Это отлично работает в роли Web (MVC) и встречается иногда только в роли рабочего (conn string в app.config). Как я могу подтвердить, что EF не находит строку подключения? ... btw отредактировал теги на вопрос в соответствии с запросом. –

+2

Я пропустил, что это случается только иногда. В этом случае это, скорее всего, нормальная ненадежность соединений SQL Azure. См. Http://blogs.msdn.com/b/sqlazure/archive/2013/01/02/10011247.aspx для фона и https://entityframework.codeplex.com/wikipage?title = Connection% 20Resiliency% 20Spec для работы, которую мы делаем в EF6 вокруг этого. –

ответ

1

Благодаря Артуру Викерсу, который прокомментировал мой вопрос, я продолжу и сделаю это с ошибками переходного процесса из-за подключения Azure SQL Database. Я так и не смог полностью доказать это, однако, я создал SQL VM на Azure и создал свою БД, а затем изменил приложение облачных сервисов, чтобы вместо этого указать на это БД.

контролировала журналы, и не видели одни и те же вопросы, которые еще ...

Один из возможных вариантов, если я вернусь к Azure SQL дб катить свою собственную логику повторных попыток с помощью Transient Fault Handling блок от Microsoft P & P, или используйте проект, например, ReliableDbProvider Роб Мура (https://github.com/robdmoore/ReliableDbProvider).

Когда EF6 выходит, я рассмотрю использование встроенных возможностей для временных ошибок.

Надеюсь, это поможет кому-то еще.