Pregunta

Nuestra aplicación sigue el enfoque de mantener un DataContext por hilo/httpContext, utilizando la clase DataContextFactory descrita por Rick Strahl en su Blog, incluida la enmienda a la clave mencionada por Richard (uso de type.AssemblyqualifiedName).

La solución parecía sólida (aunque en la mayoría de los casos un enfoque diferente puede ser mejor), sin embargo, mientras uso esto, he visto errores intermitentes que aparecen en la aplicación:

ExecuteReader requiere una conexión abierta y disponible. El estado actual de la conexión está cerrado.

Accedo al DataContext a lo largo del código utilizando la siguiente propiedad, que es parte de la clase de mi DataContext:

/// <summary>
/// Returns the current datacontext for the thread or HttpContext, creating one if it does not exist.
/// </summary>
public static SharedDataContext Current
{
    get
    {
        return DataContextFactory.GetScopedDataContext<SharedDataContext>();
    }
}

Al ser intermitente, me está costando fijar esto. ¿Alguien sabe lo que podría hacer mal o tener una buena idea de cómo podría depurar este problema?


Tenga en cuenta que esto podría ser un duplicado del sin respuesta pregunta aquí

¿Fue útil?

Solución

Ahora utilizamos una DataContextFactory personalizada que mantiene DataContexts por transacción. El único otro cambio principal fue el uso de [Threadstatic] para las propiedades, en lugar de acceder manualmente a través de Thread.get/SetData

Dado que este cambio ya no parece aparecer, y como no se han presentado otras respuestas, estoy sugiriendo [Threadstatic] como la solución

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top