¿Cuál es la diferencia entre log4net.ThreadContext y log4net.LogicalThreadContext?

ACTUALIZADO el 18/11/2014 - Mientras navegaba por el repositorio de origen log4net, descubrí que la implementación de LogicalThreadContext se modificó en noviembre de 2011 para que almacene sus propiedades usando CallContext.LogicalSetData (y las obtiene usando LogicalGetData). Esto es importante porque eso significa que LogicalThreadContext ahora debería funcionar correctamente. Cualquier dato almacenado en LogicalThreadContext debe "fluir" a cualquier subproceso o tarea secundaria. Esto se compara con ThreadContext (y la antigua implementación de LogicalThreadContext) donde los datos almacenados en el contexto permanecerían locales en el hilo actual y NO fluirían a hilos / tareas secundarios.

Si está interesado, aquí está el cambio:

http://svn.apache.org/viewvc/logging/log4net/trunk/src/log4net/Util/LogicalThreadContextProperties.cs?r1=1165341&r2=1207948&diff_format=h

Esperemos que alguien que esté pasando por esta vieja pregunta encuentre útil esta información.

log4net proporciona dos objetos diferentes de "contexto de subproceso":ThreadContext yLogicalThreadContext, cada uno de los cuales tiene una bolsa de propiedades, Propiedades. ThreadContext tiene unThreadContextProperties bolsa mientras LogicalThreadContext tiene unLogicalThreadContextProperties bolso.

ThreadContext es quizás más comúnmente conocido como "MDC". LogicalContext es quizás más comúnmente conocido como "LDC". Usaré el nombre corto para el resto de esta publicación.

MDC.Properties se implementa utilizandoSystem.Threading.Thread.SetData mientras LDC.Properties se implementa usandoSystem.Runtime.Remoting.Messaging.CallContext.SetData.

A modo de comparación, NLog solo expone "MDC" (ahora conocido como MappedDiagnosticContext) para almacenar propiedades locales de subprocesos. La implementación de NLog usa System.Threading.Thread.SetData, por lo que su implementación es la misma que la de log4net.

Tanto en log4net como en NLog, las propiedades "MDC" se almacenan en un diccionario que se almacena en el almacenamiento local de subprocesos.

En un caso como este, ¿habría sido equivalente almacenar el diccionario en una decoración variable de miembro de clase, alterado con [ThreadStatic]?

[ThreadStatic]
private static IDictionary<string, string> threadProperties;

¿Cuál será la declaración equivalente (o similar) usando la nueva clase ThreadLocal de .NET 4.0?

En definitiva, ¿cuál es la diferencia real y práctica entre LDC y MDC? Incluso después de leer los temas de MSDN vinculados anteriormente, no me queda claro. ¿Cuándo usarías realmente uno sobre el otro? Parece que la gran mayoría de las referencias / ejemplos que veo para log4net y el contexto es para GDC (global, que entiendo), NDC (anidado, que también entiendo) y MDC. La mayoría de las referencias que puedo encontrar a LDC (o LogicalThreadContext) cuando busco en Google están relacionadas con los registros en los repositorios de código fuente de log4net, no con el uso en el mundo real. LDC casi nunca aparece en preguntas o ejemplos.

Encontréesta enlace que ofrece información bastante buena sobre la diferencia de uno de los desarrolladores de log4net, Nicko Cadell, pero todavía no me queda claro.

Una pregunta más amplia, no directamente relacionada con log4net es, ¿cuál es la diferencia práctica entre Thread.SetData y CallContext.SetData?

De acuerdo con laCallContext Artículo de MSDN, los datos de CallContext se pueden propagar a otro AppDomain. Para propagarse, un elemento de datos almacenado en CallContext debe exponer elILogicalThreadAffinative interfaz. Entonces, esa parece ser una diferencia entre Thread.SetData y CallContext.

Según el enlace de Nicko Cadell, log4net no implementa ILogicalThreadAffinative, por lo que las propiedades de LDC no se propagarán.

Tal vez hay suficiente aquí para poder responder mi propia pregunta, tal vez no. Todavía estoy trabajando en la comprensión.

Si usa log4net, ¿usa MDC, LDC, ambos? Si usa MDC, ¿es porque la mayoría de los ejemplos del "mundo real" parecen usarlo? Si usa LDC, ¿tiene una razón específica para usarlo? Si usa ambos, ¿cómo elige cuándo usar cuál?

Tenga en cuenta que he visto algunos artículos sobre MDC (y tal vez LDC) tal vez no funcionen correctamente en las aplicaciones ASP.net debido al cambio de hilo. No estoy particularmente interesado en este problema ya que no estoy trabajando en ASP.net.

En realidad, he encontrado un par de publicaciones útiles aquí en SO que podrían contribuir a la discusión:

¿Cuáles son las mejores prácticas para usar el almacenamiento local de subprocesos en .NET?

.Net: ¿Hilo lógico y almacenamiento local de hilo?

¡Gracias por adelantado!

Respuestas a la pregunta(1)

Su respuesta a la pregunta