III SecuencialidadRecuperabilidad

Vista previa del material en texto

Secuencialidad
Toda planificación secuenciable en cuanto a conflictos es 
también secuenciable en cuanto a vistas, pero no ocurre lo 
mismo a la inversa (la secuencialidad en cuanto a conflictos es 
más restrictiva).
En cuanto a conflictos
Una planificación P es secuenciable en cuanto a conflictos si es equivalente en cuanto 
a conflictos a una planificación secuencial:
Una planificación P es equivalente en cuanto a conflictos a una planificación 
secuencial si P se puede transformar en otra planificación P' por medio de una serie 
de intercambios de instrucciones no conflictivas:
* No operar sobre el mismo elemento de datos
*Operar sobre el mismo elemento de datos, pero ninguna de ellas constituye una 
operación de escritura
En cuanto a vistas
Una planificación P es secuenciable en cuanto a vistas si es equivalente en cuanto a 
vistas a una planificación secuencial.
Una planificación P es equivalente en cuanto a vistas a una planificación secuencial si 
P se puede transformar en otra planificación p* a través del cumplimiento de 3 
condiciones o reglas:
* Si la transacción lee el valor inicial de Q en P, entonces debe hacerlo también en P'
* Si la transacción lee Q en P y el valor lo ha producido otra transaccion, entonces 
también debe hacerlo en P'
* La transacción que realice la última operación de escribir Q en P debe hacerlo 
también en P'
Recuperabilidad
Una planificación es recuperable cuando se puede deshacer 
(hacer ROLLBACK) cualquiera de sus transacciones. Permite 
resolver los problemas que ocurren cuando una de las 
transacciones concurrentes falla.
La recuperabilidad se basa en determinar en qué momentos 
se puede comprometer una transacción y cuándo es posible 
hacer ROLLBACK. No se fija en la cuestión de la 
secuencialidad.
Es deseable evitar el retroceso en cascada, ya que provoca un 
aumento significativo del trabajo necesario para deshacer 
cálculos.
La recuperabilidad busca que las transacciones puedan hacer 
ROLLBACK en algún momento y que eso se pueda resolver 
sin tener que deshacer otras transacciones involucradas. Es la 
forma de prevenir la lectura sucia (dependencia no 
confirmada) de datos.
Con retroceso en 
cascada
Fenómeno en el cual un fallo en una única transacción provoca una serie de 
retrocesos de transacciones. Esto ocurre cuando dichas transacciones en curso leen 
datos que ha escrito previamente la transacción que falló
Sin retroceso en cascada
Planificaciones recuperables en las que, para todo par de transacciones 𝑇𝑖 y 𝑇𝑗 tales 
que 𝑇𝑗 lee un elemento de datos que ha escrito previamente 𝑇𝑖, la operación de 
comprometer de 𝑇𝑗 aparece antes que la operación de lectura de 𝑇𝑗. (no dejo leer 
hasta que commit la trx anterior)