Algunas aclaraciones sobre diferentes niveles de aislamiento en la transacción de la base de datos?

Question

A continuación se reproduce la declaración escrita de Wikipedia's Isolation article sobre REPEATABLE READS

En este nivel de aislamiento, una concurrencia aplicación DBMS de control basados ​​en la cerradura sigue leer y escribir cerraduras (adquirida en los datos seleccionados) hasta el final de la transacción. Sin embargo, los bloqueos de rango no se gestionan, por lo que puede ocurrir el fenómeno de lecturas fantasmas (ver a continuación).

Mi pregunta aquí es cuándo comienza y finaliza la transacción, respectivamente.

Si tomamos el ejemplo de lecturas no repetibles con las lecturas repetibles Nivel de aislamiento en el mismo enlace, según mi entendimiento trnsaction 1 comienzan cuando la primera consulta se dispara es decir SELECT * FROM users WHERE id = 1. DBMS mantendrá el bloqueo en la tabla usuarios hasta y a menos que la transacción llegue a su fin. aquí Al final es decir cuando la conexión se retrotrae o se compromete no en la finalización de SELECT * FROM users WHERE id = 1. Hasta ese momento La transacción 2 esperará ¿Correcto?

---

Pregunta 2: - Ahora bien, si tenemos en cuenta el nivel de aislamiento competentes y comportamiento como se indica a continuación (en el mismo enlace)

Isolation level  Dirty reads Non-repeatable Phantoms 
Read Uncommitted may occur  may occur  may occur 
Read Committed  -    may occur  may occur 
Repeatable Read  -    may occur  - 
Serializable  -    -    - 

Según mi entendimiento más fiable es Serializable entonces Lectura repetible y luego Leído Comprometido pero aún he visto aplicaciones usando Read Committed. Es porque de rendimiento de lectura serializable y repetible es malo en comparación con Read Committed porque en serializable será secuencial y en caso de que de transacción tenga que esperar la liberación del bloqueo por otra transacción. ¿Correcto? Para obtener el mejor de los tres podemos usar el nivel de aislamiento como leído confirmado con SELECT FOR UPDATE (para lograr una lectura repetible). No estoy seguro de cómo podemos lograr la lectura fantasma si así lo deseamos, en caso de lectura comprometida nivel de aislamiento?

Answer 1

Oracle no admite el nivel de aislamiento REPEATABLE READ. Sin embargo, SQL Server sí lo hace, y coloca bloqueos en todas las filas seleccionadas por la transacción hasta que finaliza (es decir: se confirma o revierte). De modo que está en lo cierto, esto hará que otras transacciones esperen (si están actualizando los datos bloqueados) y puede ser perjudicial para la concurrencia.

En cuanto a la pregunta 2: Sí, cuanto más alto sea el nivel de aislamiento, peor serán sus transacciones simultáneas porque tendrán que esperar a que se liberen más bloqueos. No estoy seguro de lo que quiere decir con "obtener el mejor de los tres" usando SELECT FOR UPDATE porque SELECT FOR UPDATE colocará bloqueos de fila en todas las filas seleccionadas.

Y, por último, he aquí un fragmento del manual del Oracle en fantasma lee:

[lecturas fantasma se producen cuando] una transacción vuelve a ejecutar una consulta que devuelve un conjunto de filas que satisface una condición de búsqueda y encuentra que otra transacción confirmada ha insertado filas adicionales que satisfacen la condición.

Por ejemplo, una transacción consulta el número de empleados.Cinco minutos más tarde realiza la misma consulta, pero ahora el número ha aumentado en uno porque otro usuario insertó un registro para un nuevo empleado. Más datos satisfacen los criterios de consulta que antes, pero a diferencia de una lectura difusa, los datos leídos previamente no se modifican.

---

Referencia:

• Data Concurrency and Consistency (Oracle)
• SET TRANSACTION LEVEL (SQL Server)