Tienes razón:en el nivel de aislamiento
estándar , read committed , no es necesario envolver instrucciones de selección en transacciones. Las declaraciones seleccionadas estarán protegidas de lecturas sucias, ya sea que las incluya en una transacción o no.
connection 1: connection 2:
begin transaction
update user set name = 'Bill' where id = 1
select name from users where id = 1
rollback transaction
La declaración de selección no leerá la actualización revertida:no importa que no estén envueltos en una transacción.
Si necesita lecturas repetibles , luego envolver selecciones en una transacción predeterminada no ayuda:
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
El begin y commit las declaraciones no ayudarán aquí:el segundo select puede lea el nombre anterior, o puede leer el nuevo nombre.
Sin embargo, si ejecuta a un nivel de aislamiento más alto, como serializable o repeatable read , el grupo estará protegido de lecturas no repetibles:
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
En este escenario, la update se bloqueará hasta que se complete la primera transacción.
Los niveles de aislamiento más altos rara vez se usan porque reducen la cantidad de personas que pueden trabajar en la base de datos al mismo tiempo. En el nivel más alto, serializable , una consulta de informes detiene cualquier actividad de actualización.
