2011-02-07 4 views
12

¿Cómo manejo un DataContext de Linq-to_SQL en varios subprocesos?DataContext de Linq-to-SQL en varios subprocesos

¿Debería estar creando un DataContext global estático que todos los hilos usen y confirme cambios al final o debería crear un Contexto por hilo y usar esa instancia para todo lo que hay dentro de ese hilo?

Respuesta

15

DataContext no es seguro para subprocesos; usarlo directamente desde múltiples hilos causaría #fail; tener un contexto de datos estático global provocaría #fail y que causaría un crecimiento descontrolado de la memoria (el contexto de datos incluye un administrador de identidad y un rastreador de cambios para cada objeto recuperado; esto solo crece a medida que se tocan más objetos)

El contexto de datos idealmente se debe utilizar para una unidad de trabajo; girar uno arriba; do algo (que está limitado en su alcance, es decir, no toda la vida útil de la aplicación), y deséchelo. Entonces, IMO, la verdadera respuesta aquí es "atarlo a esa unidad de trabajo". Solo tú puedes saber qué es eso en tu aplicación; podría ser un método único, podría solicitar una página en una página web, podría ser un "tic" del temporizador en un servicio. Quién sabe ...

+0

¿Por qué no se puede subprocesar? MSDN no tiene nada sobre esto o por qué. – paIncrease

+1

@ Rancur3p1c "por qué": porque las colecciones son * raramente * seguras para subprocesos y tener el mismo contexto hablando en la misma conexión varias veces a la vez sería una pesadilla. El descargo de responsabilidad habitual está ahí: "Cualquier miembro público estático (compartido en Visual Basic) de este tipo es seguro para subprocesos. No se garantiza que ningún miembro de instancia sea seguro para subprocesos". vea http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx –

+0

@Marc Gravell: No es seguro para subprocesos no es lo mismo que fallar cuando se accede desde un subproceso diferente. El acceso a las variables globales de diferentes subprocesos se puede realizar de manera segura siempre que existan los mecanismos de bloqueo adecuados. Por el contrario, el acceso desde hilos que no son UI a elementos de UI está realmente prohibido y provocará excepciones de tiempo de ejecución. En tales casos, se requiere la invocación de subprocesos de fondo en el subproceso de interfaz de usuario. ¿En qué documentación basa su reclamo #fail? Porque lo haces sonar como el caso del hilo de la interfaz de usuario ... – Christoph

Cuestiones relacionadas