¿Cuál es el alcance del aislamiento en transacciones anidadas en SQL Server?
-
03-07-2019 - |
Pregunta
Considere el siguiente SQL:
BEGIN TRAN SET TRANSACTION ISOLATION LEVEL READ COMMITTED INSERT Bands ( Name ) SELECT 'Depeche Mode' UNION SELECT 'Arcade Fire' -- I've indented the inner transaction to make it clearer. BEGIN TRAN SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SELECT * FROM Bands COMMIT -- What is the isolation level right here? UPDATE Bands SET Name = 'Modest Mouse' WHERE Name = 'Oddest House' COMMIT
En resumen, iniciamos una transacción y establecemos su nivel de aislamiento en READ COMMITTED
. Luego hacemos algo de SQL aleatorio y comenzamos otra transacción anidada. En esta transacción, cambiamos el nivel de aislamiento a READ UNCOMMITTED
. Luego, confirmamos esa transacción y volvemos a la otra.
Ahora, supongo que después de la confirmación interna, el nivel de aislamiento vuelve a LEER COMPROMETIDO
. ¿Esto es correcto?
Solución
No creo que eso sea correcto.
Consulte las observaciones aquí: Establecer transacción
Solo uno de los niveles de aislamiento las opciones se pueden establecer a la vez, y queda establecido para esa conexión hasta se cambia explícitamente.
Otros consejos
Usted [Bob Probst] está en lo correcto. Es interesante que, de acuerdo con la documentación que vinculó:
Si emite SET TRANSACTION ISOLATION LEVEL en un procedimiento almacenado o un activador, cuando el objeto devuelve el control, el nivel de aislamiento se restablece al nivel vigente cuando se invocó el objeto. Por ejemplo, si establece REPEATABLE READ en un lote, y el batch luego llama a un procedimiento almacenado que establece el nivel de aislamiento en SERIALIZABLE, la configuración del nivel de aislamiento vuelve a REPEATABLE READ cuando el procedimiento almacenado devuelve el control al batch.
Por lo tanto, la conclusión aquí es que el NIVEL DE AISLAMIENTO DE TRANSACCIÓN ESTABLECIDO tiene afinidad de procedimiento , no afinidad de transacción (como había pensado).
¡Impresionante!