Transacciones entre contenedores

Las transacciones entre contenedores son transacciones de usuario implícitas o explícitas que incluyen llamadas a procedimientos almacenados compilados de forma nativa o operaciones en tablas optimizadas para memoria.

En SQL Server, las llamadas a procedimientos almacenados no inician una transacción. Las ejecuciones de procedimientos compilados de forma nativa en modo de confirmación automática (no en el contexto de una transacción de usuario) no se consideran transacciones entre contenedores.

Cualquier consulta interpretada que haga referencia a tablas optimizadas para memoria se considera parte de una transacción entre contenedores, ya sea ejecutada desde una transacción explícita o implícita o en modo de confirmación automática.

Aislamiento de operaciones individuales

Cada transacción de SQL Server tiene un nivel de aislamiento. El nivel de aislamiento predeterminado es Read Committed. Para usar un nivel de aislamiento diferente, puede establecer el nivel de aislamiento mediante SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

A menudo es necesario realizar operaciones en tablas optimizadas para memoria en un nivel de aislamiento diferente que las operaciones en tablas basadas en disco. En una transacción, es posible establecer un nivel de aislamiento diferente para una colección de instrucciones o para una operación de lectura individual.

Especificación del nivel de aislamiento de operaciones individuales

Para establecer un nivel de aislamiento diferente para un conjunto de instrucciones en una transacción, puede usar SET TRANSACTION ISOLATION LEVEL. En el ejemplo siguiente de una transacción se usa el nivel de aislamiento serializable como valor predeterminado. Las operaciones de inserción y selección en t3, t2 y t1 se ejecutan bajo aislamiento de lectura repetible.

set transaction isolation level serializable  
go  
  
begin transaction  
 ......  
  set transaction isolation level repeatable read  
  
  insert t3 select * from t1 join t2 on t1.id=t2.id  
  
  set transaction isolation level serializable  
 ......  
commit  

Para establecer un nivel de aislamiento para las operaciones de lectura individuales que es diferente del valor predeterminado de la transacción, puede usar una sugerencia de tabla (por ejemplo, serializable). Cada selección corresponde a una operación de lectura y cada actualización y cada eliminación corresponde a una lectura, ya que la fila siempre debe leerse antes de que se pueda actualizar o eliminar. Las operaciones de inserción no tienen un nivel de aislamiento, ya que las escrituras siempre están aisladas en SQL Server. En el ejemplo siguiente, el nivel de aislamiento predeterminado para la transacción es lectura confirmada, pero se accede a la tabla t1 con aislamiento serializable y a t2 con aislamiento de instantánea.

set transaction isolation level read committed  
go  
  
begin transaction  
 ......  
  
  insert t3 select * from t1 (serializable) join t2 (snapshot) on t1.id=t2.id  
  
  ......  
commit  

Semántica de aislamiento para operaciones individuales

Se ejecuta una transacción serializable T en aislamiento completo. Es como si cada otra transacción se hubiera confirmado antes de que T comenzara, o se hubiera iniciado después de que T se confirmó. Se vuelve más complejo cuando las distintas operaciones de una transacción tienen distintos niveles de aislamiento.

La semántica general de los niveles de aislamiento de transacciones en SQL Server, junto con las implicaciones en el bloqueo, se explica en SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

En el caso de las transacciones entre contenedores en las que diferentes operaciones pueden tener distintos niveles de aislamiento, debe comprender la semántica del aislamiento de las operaciones de lectura individuales. Las operaciones de escritura siempre están aisladas. Las escrituras en transacciones diferentes no pueden afectarse entre sí.

Una operación de lectura de datos devuelve una serie de filas que cumplen una condición de filtro.

Las lecturas se realizan como parte de una transacción T. Los niveles de aislamiento para las operaciones de lectura se pueden entender en términos de ,

Estado de compromiso
El estado de confirmación hace referencia a si se garantiza que los datos leídos estén confirmados.

(Transaccional) Coherencia
La coherencia transaccional de un conjunto de lecturas hace referencia a si todas las versiones de fila leídas están garantizadas para incluir actualizaciones de exactamente el mismo conjunto de transacciones.

Las garantías de estabilidad que el sistema ofrece a la transacción T sobre los datos leídos.
Estabilidad hace referencia a si las lecturas de la transacción son repetibles. Es decir, si las lecturas se repiten, ¿devolverán las mismas filas y versiones de fila?

Ciertas garantías hacen referencia a la hora de finalización lógica de la transacción. En general, la hora de finalización lógica es la hora en que la transacción se confirma en la base de datos. Si la transacción accede a las tablas optimizadas para memoria, el momento de finalización lógica es técnicamente el principio de la fase de validación. (Para obtener más información, consulte la explicación de la duración de la transacción en Transacciones en Memory-Optimized Tablas.

Independientemente del nivel de aislamiento, una transacción (T) siempre ve sus propias actualizaciones:

LECTURA NO COMPROMETIDA
Los datos leídos no pueden confirmarse, ser coherentes o estables. No obstante, incluirá las operaciones de escritura anteriores que realizó T.

LECTURA COMPROBADA
Los datos leídos se comprometerán.

INSTANTÁNEA
Todas las operaciones de lectura que T realiza bajo aislamiento de instantáneas tienen el mismo tiempo de lectura lógico, que es el principio de la transacción. Se garantiza que la lectura de datos se confirma y es coherente a partir del tiempo de lectura lógico. Se garantiza que la repetición de una lectura a partir del tiempo de lectura original devuelva el mismo resultado.

LECTURA REPETIDA
Se garantiza que los datos leídos están confirmados y se mantienen estables hasta el tiempo lógico de finalización de la transacción.

Serializable
Todas las garantías de REPEATABLE READ más la evitación de fantasmas y la coherencia transaccional con respecto a todas las operaciones de lectura serializables realizadas por T. La evitación de fantasmas significa que la operación de escaneo solo puede devolver filas adicionales escritas por T, pero no filas escritas por otras transacciones.

Tenga en cuenta la siguiente transacción:

set transaction isolation level read committed  
go  
  
begin transaction  
  -- remove all rows from t3; the related read operation is performed under read committed   
  -- isolation, as this is the default for the transaction  
  delete from t3  
  
  -- copy the contents from t1 to t3; the read on t1 is performed under the serializable   
  -- isolation level  
  insert t3 select * from t1 (serializable)  
  
  -- compare t3 and t1; note: the result set may not be empty, as rows may have been added   
  -- by other transaction before this select, due to the read committed isolation level  
  select * from t3 except t1  
  
  -- compare t1 and t3; note: the result set is empty, as no rows have been added to t1   
  -- since its contents were copied to t1, due to the serializable isolation level  
  select * from t1 except t3  
commit  

Esta transacción elimina todas las filas de t3 en aislamiento de lectura confirmada, copia todas las filas de t1 a t3 bajo aislamiento serializable y, a continuación, compara t1 y t3. Es posible que algunas filas [no en t1] se hayan agregado a t3 desde que se ha vaciado la tabla. No se agregó ninguna fila a t1, ya que la copia era serializable.

Aunque la lectura de t1 al final de la transacción se confirma sintácticamente, se puede serializar de forma eficaz, ya que la misma lectura se realizó anteriormente en la transacción con aislamiento serializable: la serialización garantiza que si la lectura se realiza en cualquier punto posterior de la transacción, se devuelven las mismas filas.

Transacciones entre contenedores y niveles de aislamiento

Una transacción entre contenedores puede considerarse que tiene dos lados: un lado basado en disco (para las operaciones en tablas basadas en disco) y un lado optimizado para memoria (para las operaciones en tablas optimizadas para memoria). Estos dos lados pueden tener diferentes niveles de aislamiento. De hecho, las operaciones de lectura individuales en cada lado pueden tener diferentes niveles de aislamiento.

El lado basado en disco de una transacción determinada T alcanza un determinado nivel de aislamiento X si se cumple una de las condiciones siguientes:

• Comienza en X. Es decir, el valor predeterminado de la sesión era X, ya sea porque ejecutó SET TRANSACTION ISOLATION LEVELo es el valor predeterminado de SQL Server.

• Durante la transacción, el nivel de aislamiento predeterminado se cambia a X mediante SET TRANSACTION ISOLATION LEVEL.

• Una operación de lectura en una tabla basada en disco se ejecuta en el nivel de aislamiento X, mediante la sintaxis WITH (X).

El lado optimizado para memoria de T alcanza un nivel de aislamiento Y si durante la ejecución de T, cualquier operación de lectura en una tabla optimizada para memoria o cualquier procedimiento almacenado compilado de forma nativa se ejecuta en el nivel de aislamiento Y.

Considere la siguiente transacción como ejemplo. Aquí, t1 y t2 son tablas basadas en disco y t3 y t4 son tablas optimizadas para memoria.

El lado basado en disco de la transacción alcanza el nivel de aislamiento leído confirmado, ya que se inicia en ese nivel. El lado basado en disco también alcanza la lectura repetible, porque la primera operación de lectura se ejecuta bajo ese nivel de aislamiento. La eliminación al final de la transacción se ejecuta en el nivel de aislamiento de lectura confirmada, y por ello no introduce un nuevo nivel de aislamiento.

El lado optimizado para memoria de la transacción puede alcanzar uno de los dos niveles: si condition1 es true, alcanza la serializable, mientras que si es false, el lado optimizado para memoria alcanza solo el aislamiento de instantáneas.

set transaction isolation level read committed  
go  
  
begin transaction  
  select * from t1 (repeatableread)  
  
  if condition1 begin  
    insert t3 select * from t4 (serializable)  
  end  
  else begin  
    insert t3 select * from t4 (snapshot)  
  end  
  
  delete from t1  
commit  

Niveles de aislamiento admitidos para transacciones entre contenedores

Existen limitaciones en los niveles de aislamiento usados con operaciones en tablas optimizadas para memoria en transacciones entre contenedores.

Las tablas optimizadas para memoria admiten los niveles de aislamiento SNAPSHOT, REPEATABLE READ y SERIALIZABLE. En las transacciones de confirmación automática, las tablas optimizadas para la memoria son compatibles con el nivel de aislamiento READ COMMITTED.

Se admiten los siguientes escenarios:

• Transacciones entre contenedores READ UNCOMMITTED, READ COMMITTED y READ_COMMITTED_SNAPSHOT pueden acceder a tablas optimizadas para memoria bajo los niveles de aislamiento SNAPSHOT, REPEATABLE READ y SERIALIZABLE. La garantía READ COMMITTED se mantiene para la transacción; todas las filas leídas por la transacción se han confirmado en la base de datos.

• Las transacciones REPEATABLE READ y SERIALIZABLE pueden acceder a tablas optimizadas para memoria en aislamiento SNAPSHOT.

Transacciones de solo lectura entre contenedores

La mayoría de las transacciones de lectura exclusiva de SQL Server se revierten al momento de la confirmación. Dado que no hay ningún cambio para confirmar en la base de datos, el sistema simplemente libera los recursos utilizados por la transacción. En el caso de las transacciones basadas en disco de solo lectura, todos los bloqueos realizados por la transacción se liberan en este momento. En el caso de las transacciones optimizadas para memoria de solo lectura que abarcan una sola ejecución de procedimientos compilados de forma nativa, no se realiza ninguna validación.

Las transacciones entre contenedores y de solo lectura en modo de confirmación automática se revierten simplemente al final de la transacción. No se realiza ninguna validación.

Las transacciones explícitas o implícitas que abarcan múltiples contenedores realizan la validación en el momento de su confirmación si la transacción accede a tablas optimizadas para la memoria bajo aislamiento REPEATABLE READ o SERIALIZABLE. Para obtener más información sobre la validación, consulte la sección detección de conflictos, validación y confirmación de comprobaciones de dependencia en transacciones en tablas de Memory-Optimized.

Véase también

Descripción de transacciones en tablas de Memory-Optimized
Directrices para los niveles de aislamiento de transacciones con las tablas Memory-Optimized
Directrices para la lógica de reintento para transacciones en tablas de Memory-Optimized