windows - tagger - tag folders

Sesión corrupta utilizando el servicio aspnet_state

Question

Desde hace algún tiempo, hemos tenido problemas con los datos que se guardan en nuestra base de datos SQL.

A veces, los registros se guardan con datos que no coinciden con el resto de la fila, lo que hace que parezca que en algún momento los datos se intercambian por otra cosa, quizás los datos de otro usuario, antes de pasarlos a la base de datos.

Usamos TransactionScopes en todo momento con el nivel de aislamiento de ReadCommitted, lo que me hace pensar que el problema de la integridad de los datos recae en la aplicación y no en el nivel de la base de datos.

Usamos la sesión extensamente y estamos empezando a pensar que los tiempos de los datos corruptos son similares a las veces que implementamos actualizaciones en el sistema durante el día.

Usamos el servicio aspnet_state para persistir la sesión sobre los reinicios de la aplicación.

Nuestros usuarios confían en las sesiones de terminal, por lo tanto, múltiples usuarios inician sesión en el mismo servidor e inician el sistema a través de un navegador.

En el pasado, hemos notado que los usuarios inician sesión con las mismas credenciales de dominio, pero ahora estamos relativamente seguros de que los usuarios ahora inician sesión con cuentas únicas.

El 99.9% de los datos son correctos, pero hemos estado luchando por comprender qué podría estar causando este problema intermitente de integridad de datos.

Ahora estamos limitando nuestras implementaciones a horas de trabajo fuera bajo pena de muerte, pero esto no siempre es posible.

¿Alguien puede arrojar luz sobre por qué / cómo podría estar sucediendo esto?

EDITAR : ahora hemos aislado esto en la capa DAL, ver la consulta SQL devuelve un valor incorrecto en el entorno multiusuario

Answer 1

¡He estado peleando recientemente contra esto !, y tuve un problema similar al suyo, alrededor del 95% de los datos escritos fueron correctos. Miré varias razones por las cuales, el principal culpable era que algunos usuarios de la red habían descargado Chrome y abierto el registro en Chrome, rompiendo los ID de nuestra sesión mientras Chrome ignoraba las sesiones.

La otra causa fue que los usuarios no cerraban el navegador o no cerraban sesión en la aplicación, lo que permitía que el mismo usuario o un usuario completamente diferente escogiera y utilizara el ID de la sesión.

Después de introducir una verificación en el navegador y luego rechazar Chrome, educar a los usuarios para asegurarse de que cierren la sesión y hacer alguna actualización de los periodos ocupados fuera, el problema casi había desaparecido.

Me olvidé de mencionar, también en su IIS es mejor desactivar el almacenamiento en caché en el almacenamiento en caché de resultados, para el usuario y el conjunto de kernel para evitar el almacenamiento en caché.