¿Cuál es el alcance de CONTEXT_INFO en SQL Server?

Question

Estoy usando CONTEXT_INFO para pasar un nombre de usuario a un desencadenador de eliminación a los fines de una tabla de auditoría/historial. Estoy intentando comprender el alcance de CONTEXT_INFO y si estoy creando una posible condición de carrera.

Cada una de las tablas de mi base de datos tiene un proceso almacenado para manejar las eliminaciones. El proceso de eliminación de eliminación toma userId como un parámetro y establece CONTEXT_INFO en userId. Mi desencadenador de eliminación luego toma el CONTEXT_INFO y lo usa para actualizar una tabla de auditoría que indica quién borró la (s) fila (s).

La pregunta es, si dos elimina sprocs de diferentes usuarios se están ejecutando al mismo tiempo, ¿puede el CONTEXT_INFO establecido en uno de los sproc ser consumido por el disparador disparado por el otro sproc?

He visto este artículo http://msdn.microsoft.com/en-us/library/ms189252.aspx pero no tengo claro el alcance de las sesiones y los lotes en SQL Server, que es la clave para que el artículo sea útil.

Me gustaría publicar el código, pero corto de tiempo en este momento. Voy a editar más tarde si esto no es lo suficientemente claro.

Gracias de antemano por cualquier ayuda.

Answer 1

La información de contexto no tiene ámbito (en el sentido del ámbito de variables de idioma) y está vinculada a la duración de la sesión. Una vez configurado, la información de contexto permanece en el valor establecido hasta que se cierra la conexión (la sesión finaliza) o hasta que se establece un nuevo valor. Dado que la ejecución en una sesión es siempre secuencial, no hay cuestión de concurrencia.

SI establece la información de contexto en un procedimiento, cualquier desencadenante ejecutado posteriormente en esa sesión verá el valor de información de contexto recién establecido. Establecer el valor de identificación de usuario en la información de contexto, como propone, y usarlo en desencadenantes es el ejemplo típico del uso de información de contexto y es perfectamente seguro con respecto a la concurrencia, ya que básicamente no hay concurrencia de la que hablar. Si planea establecer la información de contexto en un procedimiento almacenado y luego confiar en un desencadenante que se ejecuta debido a las eliminaciones que ocurren en dicho procedimiento, entonces su lote no finalizó aún, por lo que, según el artículo que ha vinculado, recupera la información del conetxt del sys.dm_exec_requests DMV o de la función CONTEXT_INFO(). Todavía no se insertará en sys.dm_exec_sessions, eso solo puede suceder después de salir del procedimiento almacenado y finalizar cualquier otra llamada en el lote de T-SQL enviado al servidor (la 'solicitud').

Answer 2

He utilizado este método exacto para auditar en un sitio del cliente y lo han estado utilizando durante casi 6 meses sin problemas.

La información de contexto se establece en el ámbito de la conexión actual para el lote actual y cualquier lote que se inicie después de que se haya completado el lote actual. Dos usuarios en su entorno no estarían en la misma conexión, o si hay conexión compartida, aún tendrían sus propios valores si se superpusieran. Si uno venía después del otro, el segundo sobrescribía el primero, pero de todos modos ya se habría terminado con él. Al menos esta es mi comprensión de cómo funciona. Puede buscar MARS (Conjuntos de resultados activos múltiples) para obtener más información al respecto.