Vous avez raison :au niveau d'isolation
standard , read committed , vous n'avez pas besoin d'encapsuler les instructions select dans les transactions. Les instructions de sélection seront protégées contre les lectures erronées, que vous les enveloppiez ou non dans une transaction.
connection 1: connection 2:
begin transaction
update user set name = 'Bill' where id = 1
select name from users where id = 1
rollback transaction
L'instruction select ne lira pas la mise à jour annulée :peu importe qu'elles ne soient pas enveloppées dans une transaction.
Si vous avez besoin de lectures répétables , alors encapsuler les sélections dans une transaction par défaut n'aide pas :
connection 1: connection 2:
begin transaction
select name from users where id = 1
update user set name = 'Bill' where id = 1
select name from users where id = 1
commit transaction
Le begin et commit les déclarations n'aideront pas ici :la seconde select peut lisez l'ancien nom, sinon il peut lire le nouveau nom.
Cependant, si vous exécutez à un niveau d'isolement plus élevé, comme serializable ou repeatable read , le groupe sera protégé des lectures non répétables :
connection 1: connection 2:
set transaction isolation level
repeatable read
begin transaction
select name from users where id = 1
update user set name = 'Bill' where id = 1
select name from users where id = 1 |
commit transaction |
|--> executed here
Dans ce scénario, la update bloquera jusqu'à ce que la première transaction soit terminée.
Des niveaux d'isolement plus élevés sont rarement utilisés car ils réduisent le nombre de personnes pouvant travailler simultanément dans la base de données. Au plus haut niveau, serializable , une requête de rapport interrompt toute activité de mise à jour.
