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

sql-server sql-server-2008

Question

Estoy utilizando CONTEXT_INFO para pasar un nombre de usuario a un desencadenante de eliminación para los fines de una tabla de auditoría / historial. Estoy tratando de entender 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 borrado almacenado toma userId como parámetro y establece CONTEXT_INFO en userId. Mi activador de eliminación luego toma el CONTEXT_INFO y lo usa para actualizar una tabla de auditoría que indica quién eliminó la (s) fila (s).

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

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

Publicaré el código, pero corto de tiempo en este momento. Lo editaré más tarde si esto no es lo suficientemente claro.

Gracias de antemano por cualquier ayuda.

Answer 1

He utilizado este método exacto para realizar auditorías en un sitio de cliente y lo han estado usando mucho durante casi 6 meses sin problemas.

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

Answer 2

La información de contexto no tiene alcance (en el sentido de las variables del lenguaje) y está vinculada a la duración de la sesión. Una vez establecida, 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 siempre es secuencial, no se trata de la concurrencia.

Si configura la información de contexto en un procedimiento, cualquier desencadenador ejecutado posteriormente en esa sesión verá el valor de la información de contexto recién establecido. Establecer el valor de id de usuario en la información de contexto, como usted propone, y utilizarlo en los desencadenantes es el ejemplo típico del uso de información de contexto y es perfectamente seguro en lo que respecta 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 ella en un desencadenante que se ejecuta debido a las eliminaciones que ocurren en dicho procedimiento, entonces su lote aún no terminó así que, según el artículo que vinculó, recupera la información de sys.dm_exec_requests del sys.dm_exec_requests DMV o de la función CONTEXT_INFO() . Todavía no se sys.dm_exec_sessions a sys.dm_exec_sessions , que solo puede suceder después de que salga del procedimiento almacenado y finalice cualquier otra llamada en el lote de T-SQL enviado al servidor (la "solicitud").