Compartir a través de


Usar sesiones enlazadas

Las sesiones enlazadas facilitan la coordinación de las acciones entre varias sesiones iniciadas en un mismo servidor. Permiten que dos o más sesiones compartan la misma transacción y los mismos bloqueos, además de trabajar con los mismos datos sin que surjan conflictos de bloqueo. Se pueden crear sesiones enlazadas a partir de varias sesiones con la misma aplicación o desde varias aplicaciones con sesiones independientes.

Para participar en una sesión enlazada, una sesión llama a sp_getbindtoken o srv_getbindtoken (mediante Servicios abiertos de datos) para obtener un testigo de enlace. Un testigo de enlace es una cadena de caracteres que identifica de forma única cada transacción enlazada. El testigo de enlace se envía a las otras sesiones que se van a enlazar a la sesión actual. Las demás sesiones se enlazan con la transacción al llamar a sp_bindsession con el testigo de enlace recibido de la primera sesión.

[!NOTA] Las sesiones deben tener una transacción de usuario activa para que sp_getbindtoken o srv_getbindtoken funcionen correctamente.

Los testigos de enlace deben transmitirse desde el código de la aplicación que establece la primera sesión al código de la aplicación que enlaza posteriormente sus sesiones a la primera sesión. No existe ninguna una instrucción Transact-SQL o función de API que pueda utilizar una aplicación para obtener el testigo de enlace de una transacción iniciada por otro proceso. A continuación se indican algunos métodos que se pueden utilizar para transmitir un testigo de enlace:

  • Si se han iniciado todas las sesiones desde el mismo proceso de aplicación, se pueden guardar los testigos de enlace en la memoria global, o bien se pueden pasar como un parámetro a las funciones.
  • Si se han establecido las sesiones desde procesos de aplicación independientes, los testigos de enlace se pueden transmitir mediante la comunicación entre procesos (IPC), como una llamada a un procedimiento remoto (RPC) o el intercambio dinámico de datos (DDE).
  • Los testigos de enlace se pueden guardar en una tabla de una instancia del SQL Server Database Engine (Motor de base de datos de SQL Server) que puedan leer los procesos que deseen enlazar a la primera sesión.

Sólo puede haber una sesión activa a la vez en un conjunto de sesiones enlazadas. Si una sesión ejecuta una instrucción en la instancia o tiene resultados pendientes de la instancia, ninguna otra sesión enlazada podrá tener acceso a la instancia hasta que la sesión actual finalice el procesamiento o cancele la instrucción actual. Si la instancia está ocupada procesando una instrucción de otra de las sesiones enlazadas, se producirá un error que indica que el espacio de la transacción está en uso y que la sesión debería volver a intentarlo más tarde.

Cuando se enlazan sesiones, cada una de ellas mantiene su nivel de aislamiento. Si se utiliza SET TRANSACTION ISOLATION LEVEL para cambiar el valor del nivel de aislamiento de una sesión, no se verán afectados los valores de las sesiones enlazadas a ella.

Tipos de sesiones enlazadas

Los dos tipos de sesiones enlazadas son local y distribuido.

  • Sesión enlazada local
    Permite enlazar sesiones para compartir el espacio de transacciones de una sola transacción en una única instancia del Database Engine (Motor de base de datos)
  • Sesión enlazada distribuida
    Permite que las sesiones enlazadas compartan la misma transacción entre dos o más instancias hasta que toda la transacción se haya confirmado o revertido mediante el Coordinador de transacciones distribuidas de Microsoft (MS DTC).

Las sesiones enlazadas distribuidas no se identifican mediante el testigo de enlace de una cadena de caracteres, sino mediante números de identificación de transacciones distribuidas. Si una sesión enlazada está implicada en un transacción local y ejecuta un RPC en un servidor remoto con SET REMOTE_PROC_TRANSACTIONS ON, MS DTC promueve automáticamente el nivel de la transacción enlazada local a transacción enlazada distribuida y se inicia una sesión de MS DTC.

Cuándo utilizar sesiones enlazadas

En versiones anteriores de SQL Server, las sesiones enlazadas se utilizaban básicamente para desarrollar procedimientos almacenados extendidos que tenían que ejecutar instrucciones Transact-SQL en nombre del proceso que los llamaba. Pasar el proceso que realiza la llamada en un testigo de enlace como un parámetro del procedimiento almacenado extendido permite al procedimiento combinar el espacio de transacciones del proceso que realiza la llamada y, por ello, integrar el procedimiento almacenado extendido con el proceso que realiza la llamada.

En el SQL Server 2005 Database Engine (Motor de base de datos de SQL Server 2005), los procedimientos almacenados escritos mediante CLR son más seguros, escalables y estables que los procedimientos almacenados extendidos. Los procedimientos almacenados CLR utilizan el objeto SqlContext para combinar el contexto de la sesión de llamada en lugar de sp_bindsession.

Se pueden utilizar sesiones enlazadas para desarrollar aplicaciones de tres niveles en las que la lógica comercial se incorpora mediante programas independientes que funcionan en colaboración en una sola transacción comercial. Estos programas deben codificarse de forma que coordinen con precisión su acceso a la base de datos. Dado que las dos sesiones comparten los mismos bloqueos, ambos programas deben evitar intentar modificar los mismos datos a la vez. En cualquier momento sólo puede haber una sesión que realice el trabajo como parte de la transacción. No se permiten ejecuciones en paralelo. La transacción sólo se puede cambiar entre sesiones y en puntos de rendimiento bien definidos, como el momento en que han finalizado todas las instrucciones DML y se han recuperado todos los resultados.

Vea también

Otros recursos

sp_bindsession (Transact-SQL)
srv_getbindtoken (Extended Stored Procedure API)
sp_getbindtoken (Transact-SQL)
SET REMOTE_PROC_TRANSACTIONS (Transact-SQL)
Extended Stored Procedures Programmer's Reference

Ayuda e información

Obtener ayuda sobre SQL Server 2005