equivalente del lado del servidor de HttpContext?

Question

Tengo una aplicación web que utiliza actualmente el HttpContext actual para almacenar un contexto de datos LINQ. El contexto se conserva de la solicitud actual, sobre una base por usuario, por Rick Strahl de el blog :

string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x")  
Thread.CurrentContext.ContextID.ToString();

if (!HttpContext.Current.Items.Contains(ocKey))
{
    // Get new Data Context and store it in the HTTP Context
}

Sin embargo, tengo algunas secuencias de comandos que se ejecutan desde el archivo Global.asax, que no tienen una HttpContext. El HttpContext.Current es NULL , ya que el servidor es el que está haciendo la "solicitud".

¿Hay un objeto equivalente que puedo usar para almacenar el contexto de datos? Por lo que no tiene que preocuparse de volver a crearlo, y la unión / separación de objetos? Sólo quiero que persista el contexto de la vida de mis procesos.

ACTUALIZADO:

Actualmente estoy tratando de utilizar una variable estática en mi clase DAL ayudante. en la primera llamada a uno de los métodos de la clase se instancia la DataContext, y se almacena en la variable estática. Al final de mi proceso, que llamo otro método que llama a Dispose en el DataContext, y la variable estática a NULL.

Answer 1

Puede usted no sólo tiene que utilizar una variable estática específicamente para esos guiones? Eso tendrá el mismo tiempo de vida como el AppDomain. Probablemente debería pensar cuidadosamente acerca de cualquier preocupación de concurrencia, pero suena como la forma más sencilla de mantener un valor de alrededor.

(yo sólo he comprobado, y aunque una instancia de HttpApplication se puede utilizar para dar servicio a múltiples solicitudes, cada una de ellas sólo sirve una solicitud a la vez -. Lo que sugiere que varias instancias se crean para el procesamiento de solicitudes simultáneas que no tengo validado esto, pero suena como que no sería seguro para mantenerlo en una variable de instancia.)

EDIT: La respuesta de Josh sugiere que usted desea que esto sea por subproceso. Eso suena un poco extraño para mí, ya que a menos que tengas un mucho de estos eventos ocurren, usted es muy probable que sólo ven siempre a los ejecutan en diferentes hilos, por lo que todo el negocio de compartir sin sentido. Si realmente quiere ese tipo de cosas, me gustaría sugerir simplemente utilizando una variable de instancia en la clase HttpApplication derivados - exactamente por la razón descrita en el párrafo anterior:)

Answer 2

¿Por qué no usar el HttpContext actual? Las secuencias de comandos en el archivo global.asax son el resultado de una solicitud de entrada en el servidor, por lo que debería ser un contexto asociado con esa petición, que se puede agarrar.

No entiendo la necesidad de generar la clave basada en el código hash o el hilo. No va a ser una instancia independiente de HttpContext para cada petición que entra, y que instancia va a ser específica para el hilo que está procesando la solicitud. Debido a eso, la clave es más o menos valor cuando se basa en la instancia de HttpContext y el hilo.

Además, ¿cómo deshacerse de la DataContext cuando haya terminado? Se implementa IDisposable por una razón, por lo que recomiendo para una instancia compartida de esta manera.

---

Actualizar

En los comentarios, esto indica que hay un temporizador que ejecuta que se está ejecutando los scripts. En lugar del temporizador, yo recomendaría la creación de una tarea programada que llamar a un servicio web o una página predeterminada en el sitio que va a realizar la tarea. A continuación, siempre tendrá un HttpContext trabajar con ellos.

Answer 3

HttpContext.Current es un método estático y debería estar disponible desde cualquier lugar, siempre y cuando el código se ejecuta en el contexto de una solicitud.

En el caso de que su ejecución no en el contexto de una solicitud, usted podría considerar el uso Application.Cache pero no sería recomendable el que sostiene un DataContext abierta. No soy muy famillar con LINQ a las entidades, por lo que podría estar equivocado, pero por lo general el almacenamiento en caché de base de datos artículos relacionados, tales como conexiones es malo.

Me gustaría también recomendamos que considere la lógica se mueve fuera de su global.asax y para un servicio de Windows. Esto permitirá tener un mayor control sobre estas tareas, por ejemplo, puede cerrarlas seperatley del sitio web.

Editar

JS señala que podría utilizar una variable estática. También se podría definir una variable de instancia marcada con el atributo ThreadLocal. Esto dará a cada hilo de su propia copia de la variable, y puede eliminar la contención. Puesto que desea que cada hilo tenga su propia copia de todos modos.

Answer 4

¿Hay una razón por la cual éstos deben ser manejados de la misma manera que los otros DataContexts? Me parece que si el contexto sólo es necesaria dentro de la rutina de manejo de eventos, que no es necesario para mantenerlo alrededor. Especialmente si se trata de Application_Start (como por su comentario), no me molestaría el almacenamiento en caché en cualquier lugar -. Sólo lo utilizan a nivel local y pasarlo a los otros métodos, según sea necesario

Answer 5

Ajuste el DataContext como el parámetro de estado cuando se crea el temporizador. Sobre la base de la información que al día de los comentarios, me parece que su DataContext está más relacionado con los contadores de tiempo que cualquier otra cosa.

También evitar el uso de la misma DataContext para diferentes temporizadores, ya que terminaría con modificaciones diversas de los diferentes temporizadores. También asegúrese de que su misma lógica temporizador no se ejecuta dos veces, ya que podría causar el mismo período demasiado corto, es decir sin ningún control.