En general, hay 3 tipos de cronograma basados en la recuperabilidad que se detallan a continuación:
- Calendario recuperable: Las
transacciones deben comprometerse en orden. Puede ocurrir un problema de lectura sucia y un problema de actualización perdida. - Programación sin cascada:
lectura sucia no permitida, significa que no se permite leer los datos escritos por una transacción no confirmada. Puede ocurrir un problema de actualización perdida. - Horario estricto:
no se permite ni la lectura sucia ni el problema de actualización perdida, lo que significa que no se permite leer o escribir los datos escritos por una transacción no confirmada.
Problema de lectura sucia :
cuando una transacción lee datos de escritura no confirmada en otra transacción, se conoce como lectura sucia . Si esa transacción de escritura falló, y esos datos escritos pueden actualizarse nuevamente. Por lo tanto, esto causa un problema de lectura sucia .
En otras palabras,
La lectura de los datos escritos por una transacción no confirmada se denomina lectura sucia.
Se denomina lectura sucia porque siempre existe la posibilidad de que la transacción no confirmada se revierta más adelante. Por lo tanto, una transacción no confirmada puede hacer que otras transacciones lean un valor que ni siquiera existe. Esto conduce a la inconsistencia de la base de datos.
Por ejemplo, supongamos que la transacción 1 actualiza una fila y la deja sin confirmar, mientras tanto, la transacción 2 lee la fila actualizada. Si la transacción 1 revierte el cambio, la transacción 2 habrá leído datos que se considera que nunca existieron.
Tenga en cuenta que no hay problema de lectura sucia, es una transacción que está leyendo de otra transacción confirmada. Por lo tanto, no se requiere reversión.
Reversión en cascada:
si en una programación, el error de una transacción hace que varias otras transacciones dependientes se reviertan o cancelen, entonces dicha programación se denomina Reversión en cascada, Cancelación en cascada o Programación en cascada. Simplemente conduce a la pérdida de tiempo de CPU.
Estos retrocesos en cascada ocurren debido a problemas de lectura sucia .
Por ejemplo, la transacción T1 escribe una x no confirmada que lee la transacción T2. La transacción T2 escribe una x no confirmada que lee la transacción T3.
Supongamos que en este punto T1 falla.
T1 debe revertirse, dado que T2 depende de T1, T2 debe revertirse, y dado que T3 depende de T2, T3 debe revertirse.
Debido a la reversión de T1, todos los T2, T3 y T4 también deben revertirse (problema de lectura sucia en cascada).
Este fenómeno, en el que el error de una sola transacción da lugar a una serie de reversiones de transacciones, se denomina reversión en cascada .
Horario sin cascada:
este horario evita todos los posibles problemas de lectura sucia .
En Cascadeless Schedule, si una transacción va a realizar una operación de lectura en un valor, tiene que esperar hasta que se confirme la transacción que está realizando la escritura en ese valor. Eso significa que no debe haber lectura sucia . Debido a que el problema de lectura sucia puede causar una reversión en cascada , que es ineficiente.
Cascadeless Schedule evita cancelaciones/retrocesos en cascada (ACA). Los programas en los que las transacciones leen valores solo después de que se confirmen todas las transacciones cuyos cambios van a leer se denominan programas sin cascada. Evita que un solo aborto de transacción conduzca a una serie de reversiones de transacciones. Una estrategia para evitar abortos en cascada es prohibir que una transacción lea cambios no confirmados de otra transacción en el mismo cronograma.
En otras palabras, si alguna transacción Tj quiere leer el valor actualizado o escrito por alguna otra transacción Ti, entonces la confirmación de Tj debe leerlo después de la confirmación de Ti.
Tenga en cuenta que el programa Cascadeless solo permite operaciones de lectura confirmadas. Sin embargo, permite operaciones de escritura no confirmadas.
También tenga en cuenta que los Horarios sin cascada siempre son recuperables , pero es posible que todas las transacciones recuperables no sean Horarios sin cascada.
Publicación traducida automáticamente
Artículo escrito por Mithlesh Upadhyay y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA