Quelle est la portée de l'isolement dans les transactions imbriquées dans SQL Server?
-
03-07-2019 - |
Question
Considérez le code SQL suivant:
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 résumé, nous commençons une transaction et définissons son niveau d'isolement sur READ COMMITTED
. Nous faisons ensuite du SQL aléatoire et commençons une autre transaction imbriquée. Dans cette transaction, le niveau d'isolation est remplacé par READ UNCOMMITTED
. Nous commettons ensuite cette transaction et retournons à l'autre.
Maintenant, je suppose que, après la validation interne, le niveau d'isolement revient à READ COMMITTED
. Est-ce correct?
La solution
Je ne pense pas que ce soit correct.
Voir les remarques ici: Définir la transaction
Un seul niveau d'isolement les options peuvent être définies à la fois, et reste réglé pour cette connexion jusqu'à ce que il est explicitement changé.
Autres conseils
Vous [Bob Probst] avez raison. Il est intéressant de noter que, selon la documentation , vous avez lié:
Si vous émettez SET TRANSACTION ISOLATION LEVEL dans une procédure stockée ou un déclencheur, lorsque l'objet retourne le contrôle, le niveau d'isolation est réinitialisé au niveau en vigueur lors de l'appel de l'objet. Par exemple, si vous définissez REPEATABLE READ dans un lot et que celui-ci appelle ensuite une procédure stockée définissant le niveau d’isolement sur SERIALIZABLE, le paramètre de niveau d’isolement repasse à REPEATABLE READ lorsque la procédure stockée redonne le contrôle au lot.
Le résultat est donc que SET TRANSACTION ISOLATION LEVEL a une affinité de procédure , et non une affinité de transaction (comme je l’avais pensé).
Génial!