"ошибка: 19 - физическое соединение не используется" с доступом OWIN в базе данных Azure
Я пробовал все остальные сообщения о страшной "ошибке 19" и обнаружил, что немногие с ответами не применяются или не помогают, следовательно, это новое сообщение. Это очень серьезная потенциальная проблема для всех пользователей Azure + EF.
Первое появление:
Я использую последнюю версию всего в проекте VS2013 EF6.1 Razor (пакеты перечислены в конце). База данных размещена на SQL Azure.
После запуска моего webapp несколько раз (в среде dev) я получаю эту ошибку: A transport-level error has occurred when receiving results from the server. (provider: Session Provider, error: 19 - Physical connection is not usable)
Линия, на которой он умирает, всегда такова:
![enter image description here]()
Я понимаю, что ошибка связана с пулом соединений (и запуском соединений), но я не могу обнаружить утечку где-нибудь.
Когда я обращаюсь к членству в OWIN и другим функциям базы данных во всем приложении, у меня есть DatabaseContoller, из которого наследуются все остальные контроллеры. Это создает все соответствующие компоненты и избавляет от них.
DatabaseController.cs
[Authorize]
public class DatabaseController : Controller
{
#region properties
/// <summary>
/// User manager - attached to application DB context
/// </summary>
protected UserManager<ApplicationUser> UserManager { get; set; }
/// <summary>
/// Role manager - attached to application DB context
/// </summary>
protected RoleManager<IdentityRole> RoleManager { get; set; }
/// <summary>
/// Application DB context
/// </summary>
protected ApplicationDbContext ApplicationDbContext { get; set; }
/// <summary>
/// Database context used by most controllers
/// </summary>
protected ApplicationEntities Context { get; set; }
#endregion properties
#region Constructors
public DatabaseController()
{
this.Context = new ApplicationEntities ();
this.ApplicationDbContext = new ApplicationDbContext();
this.UserManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(this.ApplicationDbContext));
this.RoleManager = new RoleManager<IdentityRole>(new RoleStore<IdentityRole>(this.ApplicationDbContext));
this.UserManager.UserValidator = new UserValidator<ApplicationUser>(UserManager) { AllowOnlyAlphanumericUserNames = false };
}
#endregion Constructors
protected override void Dispose(bool disposing)
{
if (disposing)
{
if (UserManager != null)
{
this.UserManager.Dispose();
this.UserManager = null;
}
if (this.RoleManager != null)
{
this.RoleManager.Dispose();
this.RoleManager = null;
}
if (this.ApplicationDbContext != null)
{
this.ApplicationDbContext.Dispose();
this.ApplicationDbContext = null;
}
if (this.Context != null)
{
this.Context.Dispose();
this.Context = null;
}
}
base.Dispose(disposing);
}
}
Установленные пакеты
<package id="Antlr" version="3.5.0.2" targetFramework="net45" />
<package id="bootstrap" version="3.1.1" targetFramework="net45" />
<package id="EntityFramework" version="6.1.0" targetFramework="net45" />
<package id="jQuery" version="1.11.0" targetFramework="net45" />
<package id="jQuery.Validation" version="1.11.1" targetFramework="net45" />
<package id="json2" version="1.0.2" targetFramework="net45" />
<package id="Microsoft.AspNet.Identity.Core" version="2.0.0" targetFramework="net45" />
<package id="Microsoft.AspNet.Identity.EntityFramework" version="2.0.0" targetFramework="net45" />
<package id="Microsoft.AspNet.Identity.Owin" version="2.0.0" targetFramework="net45" />
<package id="Microsoft.AspNet.Mvc" version="5.1.1" targetFramework="net45" />
<package id="Microsoft.AspNet.Razor" version="3.1.2" targetFramework="net45" />
<package id="Microsoft.AspNet.Web.Optimization" version="1.1.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi" version="5.1.2" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Client" version="5.1.2" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Core" version="5.1.2" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.WebHost" version="5.1.2" targetFramework="net45" />
<package id="Microsoft.AspNet.WebPages" version="3.1.2" targetFramework="net45" />
<package id="Microsoft.jQuery.Unobtrusive.Validation" version="3.1.2" targetFramework="net45" />
<package id="Microsoft.Owin" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Host.SystemWeb" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.Cookies" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.Facebook" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.Google" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.MicrosoftAccount" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.OAuth" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Owin.Security.Twitter" version="2.1.0" targetFramework="net45" />
<package id="Microsoft.Web.Infrastructure" version="1.0.0.0" targetFramework="net45" />
<package id="Modernizr" version="2.7.2" targetFramework="net45" />
<package id="Newtonsoft.Json" version="6.0.2" targetFramework="net45" />
<package id="Owin" version="1.0" targetFramework="net45" />
<package id="Owin.Security.Providers" version="1.3.1" targetFramework="net45" />
<package id="Respond" version="1.4.2" targetFramework="net45" />
<package id="WebGrease" version="1.6.0" targetFramework="net45" />
Предполагая, что это утечка соединения, как я могу отслеживать источник утечки?
Если вам нужна дополнительная информация, просто спросите.
Обновление: 22 мая 2014 г. Вторая баунти предложила
У меня все еще есть одна и та же проблема, с некоторыми небольшими изменениями проекта, сделанными с момента последнего опубликования, поэтому опубликуем последние данные ниже.
Я добавил Connection Lifetime=3;Max Pool Size=3; в мои строки подключения на основе этого сообщения.
Обновление: 23 мая 2014 г. По-прежнему происходит ошибка
На следующий день после отладки несколько десятков раз эта ошибка вернулась.
Обновление: 11 июня 2014 года
После 2 раздач и бесчисленных расследований Google (на этот раз я не отвечаю), я должен предположить, что это недостаток в Entity Framework 6, который я как-то вызываю, чтобы появиться.
Дополнительная информация:
У меня была такая же ошибка в проекте WinForm, подключившись к Azure. В этом случае я случайно не очистил список сущностей после добавления 20 новых элементов.
Каждый раз, когда запускался код, он добавлял еще 20 записей и обновлял поле DateModified для всех них. К тому моменту, когда он заработал 1700 обновляемых записей, он внезапно дал страшную "ошибку 19 - физическое соединение не используется". После этого мне пришлось перезапустить мой отладочный IIS, чтобы он вообще работал.
Очевидно, что в коде было огромное количество обновлений, и, возможно, что-то об этом поможет кому-то подумать.
Ответы
Ответ 1
Ошибка 19 не является комм-ошибкой! (или не только сообщение об ошибке)
Просто убедитесь, что у вас есть все необходимые вызовы .Include(x=>x.ForeignTable) в запросе LINQ to SQL!
Обновлен август 2015 г. (возможное решение, по крайней мере, для некоторых сценариев):
У нас просто был 100% -ый репродукт по этой проблеме, который мы смогли решить с пробным и пробным тестированием, поэтому он может быть решением или, по крайней мере, дать ключ к поиску.
Сценарий:
- Ошибка произошла только в версиях релизов, запущенных под IIS. Это не произошло при отладке или под IIS Express.
- Мы также включили профилирование SQL, чтобы увидеть, когда/где на самом деле был удален сервер.
- Этот запрос запрашивал сопоставление записей, а затем создавал модели представления в
foreach итерации результатов (т.е. ленивая оценка). Модель просмотра зависела от значения в связанной таблице запрашиваемого объекта.
Тестирование:
Первая попытка: удалить любые сложные фильтры в запросе
- Результат: все еще не удалось с ошибкой 19
Вторая попытка: добавить ToList() в запрос, чтобы принудительно выполнить запрос до завершения.
- Результат: успешно!!! (очевидно, что-то происходит здесь)
Третья попытка: удалить ToList() и добавить .Include(x=>x.ForeignTable) в запрос, чтобы принудительно включить связанные данные.
Моя новая теория:
Если вы случайно оставьте Include внешней таблицы, EF будет случайным образом не получать связанные данные при ленивой оценке. Это может привести к печально известной ошибке 19.
Поскольку в Identify Framework есть отношения с внешними ключами, вы можете предположить, что в запросе где-то в OWIN есть также отсутствующий .Include() или эквивалент. Это может вызвать случайную проблему при использовании OWIN или других запросов.
Примечание:
- Ключевым моментом, который следует убрать, является то, что ошибка 19 не является ошибкой comms. Запросы попадают на SQL-сервер. Это проблема на стороне клиента, поскольку не удалось получить связанные данные.
Пауза для аплодисментов (мы очень рады, что нашли это):)
Обновлено 28 августа 2015 года:
Сегодня у меня была ужасная ошибка 19, которая подключалась к локальной базе данных SQL (обычно это была проблема с Azure для меня). Основываясь на результатах выше, я просто добавил инструкцию .Include(x=>x.ForeignTable), где это уместно, и проблема исчезла! Это, по-видимому, является проблемой EF, которая не всегда может использовать информацию о связанной таблице lazy-load.
Ответ 2
Вы попробовали SqlAzureExecutionStrategy? Похоже, что соединение отключено, но с этой стратегией EF следует автоматически повторять попытку для повторного подключения.
http://msdn.microsoft.com/en-us/data/dn456835.aspx
