Solo quería ejecutar esto por todos ustedes para ver si hay ideas brillantes ya que he agotado todas mis ideas después de un día completo, una noche y una mañana de búsqueda. Los problemas que nos encontramos invariablemente se centran en la conectividad de la base de datos cuando se utiliza de forma concurrente (prueba de selenio), p. tiempos de espera, conexiones caídas/cerradas, servidor de base de datos inalcanzable.Problemas de uso simultáneo de la base de datos Azure
El problema parece estar restringido a Azure ya que todavía tenemos que enfrentar el problema localmente incluso cuando ejecutamos la misma prueba de selenio en el mismo código que apunta a la misma base de datos (SQL Azure) por lo que indicaría que algún problema con la conectividad de la base de datos de salida en SQL Azure. Hasta ahora hemos intentado el siguiente:
- Azure manejo de errores transitorios - Tenemos la lógica de reintento en el lugar para cuando hay un problema temporal con el servicio de SQL Azure en sí.
- Cambiar el protocolo de comunicación: hemos intentado con TCP y con Canalizaciones con nombre y nos encontramos con el mismo problema con ambos.
- Ajustar el intervalo de tiempo de espera de conexión de la base de datos: hemos intentado aumentar esto en vano.
- Adición de varios conjuntos de resultados activos: hemos agregado esto a la cadena de conexión en vano.
- Comprobación de estado de conexión en cada consulta - Cuando devolvemos el DataContext, verificamos su conexión y lo reabremos cuando sea necesario.
- agrupación de conexiones desactivada: también lo hemos intentado sin éxito .
patrón de diseño Cambiado - Incluso fuimos a las longitudes de implementar una Unidad de patrón de diseño de trabajo, donde las conexiones de base eran ser despedido y eliminado después de cada unidad de trabajo, pero esto causado problemas en otros lugares con carga diferida , pasar objetos a los métodos y hubiera sido una revisión demasiado importante en este punto .
Cambiar tamaño de papel - La última cosa que se me ocurre a intentar es el tamaño papel en caso de cualquier restricción conexión implícita de Windows Azul - que actualmente está desplegando así que todavía hay una pequeña oportunidad que podría funcionar!
La infraestructura del sitio es el siguiente:
- clase DataContext (se extiende DbContext) que es un contexto Código Primera EF.
- La clase BusinessLayer contiene un DataContext privado, no estático. DataContext es un constructor inyectado en cada clase Manager/Helper.
- La clase BusinessLayerService contiene una instancia pública, hilo BusinessLayer.
- El sitio MVC usa BusinessLayerService.Instance para acceder a las clases de administrador que consultan y actualizan el DataContext que se han pasado.
Cualquier ayuda sería muy apreciada.
ACTUALIZACIÓN: Aumentamos el tamaño de la VM a Medio y todo lo que hizo fue decir que el mismo problema tardó más en ocurrir.
Cuando los problemas empezaron occuring, un miembro del equipo tomó nota de la siguiente excepción ocurrió:
InvalidOperationException: La ejecución del comando requiere una conexión abierta y disponible. El estado actual de la conexión está roto.
Esto comenzó a ocurrir cada vez que se golpeaba la base de datos (no era específico de un área determinada de código).
Excelente pregunta. +1 –
¿Has probado con el enfoque clásico ADO.Net en lugar de EF? Me dijeron que la gente tenía más problemas con EF que con ADO.Net cuando trabajaba con SQL Azure. –
@GauravMantri El problema es que este y otros proyectos que ya tenemos en la naturaleza usan EF, por lo que cambiar a ADO.NET sería un proceso largo y costoso :) – mattytommo