multithreading wcf thread-safety wcf-extensions

multithreading - WCF Operation.Context no Thread safe?



thread-safety wcf-extensions (1)

Estoy revisando el código de un servicio WCF. En el encabezado de cada mensaje, inyectamos datos que el servicio usará más adelante para crear una cadena de conexión a una base de datos. Esto se debe a que el servicio será utilizado por varios sitios diferentes, cada uno con su propia base de datos que el servicio debe consultar. Utilizamos la extensibilidad wcf. Tenemos un MessageInspector personalizado que, después de recibir la solicitud, extrae los datos del encabezado del mensaje, crea un contexto (que implementa IExtension) y lo agrega a OperationContext.Current.Extensions. Antes de enviar la respuesta, el contexto personalizado se elimina de la colección de Extencions.

Este es un patrón bastante común, como se discute aquí:

¿Dónde almacenar los datos para la llamada WCF actual? ¿Es seguro ThreadStatic?

y aquí:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/319cac66-66e8-4dfe-9a82-dfd289c9df1f/wcf-doesnt-have-session-storage-so-where-should-one-store-call-specific-data?forum=wcf

Todo esto funciona bien siempre que el servicio reciba una solicitud, la procese, envíe la respuesta y reciba la siguiente solicitud. Pero, ¿qué sucede si el servicio recibe una solicitud y, antes de poder responderla, recibe una segunda solicitud? Construí una pequeña aplicación de consola para probarlo. Envío 2 mensajes de 2 subprocesos diferentes, hice que el servicio wcf esperara 2 segundos, para asegurar que la segunda solicitud llegue antes de que se complete la primera y esto es lo que recibí:

Id del sitio: test1450; Sesión: uuid: 2caf47cf-7d46-4d72-9275-d9c037fa0e70; id = 2: Id de hilo: 6

Id del sitio: test1450; Sesión: uuid: 2caf47cf-7d46-4d72-9275-d9c037fa0e70; id = 3: Id de rosca: 22

Parece que wcf crea 2 sesiones ejecutándose en 2 subprocesos diferentes, pero el Id. Del sitio es el mismo. No debería. A juzgar por esto, parece que OperationContext.Current.Extensions es una colección compartida entre hilos. En este momento me inclino a pensar que mi prueba está equivocada y me perdí algo.

¿Alguien ha intentado algo similar y descubrió que OperationContext.Current no es seguro para subprocesos?


OperationContext.Current como otras propiedades similares, como HttpContext.Current tiene valores afines (o hilos estáticos). Por lo tanto, son seguros para subprocesos en el sentido de que varios subprocesos pueden leerlos, pero diferentes subprocesos obtendrán diferentes instancias. Pueden considerarse como diccionarios entre subprocesos e instancias específicas.

Así que en este contexto no son seguros para subprocesos.

Las solicitudes son atendidas por un grupo de subprocesos, por lo que las solicitudes simultáneas tendrán diferentes ID de subprocesos. (Hasta un punto donde el grupo de subprocesos está lleno, las solicitudes se retendrán)