Algunas soluciones

4.- 2PL básico con prioridad y bloqueo ordenado.

Primero, hay que determinar los posibles usos de
las prioridades. Por una parte, nos pueden servir
para lidiar con potenciales deadlocks, aumentando
la prioridad de las transacciones que se están
demorando demasiado, hasta pasar un cierto límite,
en el cual es necesario forzar la ejecución de
éstas. Por otra parte, nos pueden servir para
elegir qué instrucción abortar primero ante un
presunto deadlock. (Un último objetivo puede estar
en el órden de las transacciones, para permitir
ejecutar las transacciones más rápidas primero
para elevar el tiempo promedio de respuesta del
sistema, pero esto se sale de la discusión.)

Usar prioridades acordes al "envejecimiento" de
las transacciones nos puede ayudar a evitar pre-
suntos deadlocks y starvation. Si una transacción
está demasiado tiempo inactiva en un bloqueo o
en espera de atención, se puede forzar su atención
pasado un cierto grado de prioridad. Si está en
un eventual deadlock, se deberán abortar todas
las transacciones involucradas y ejecutar la más
prioritaria primero. En el caso de starvation,
se puede esperar a que las transacciones actuales
terminen y se comience a atender la transacción
dejada de lado, para luego seguir atendiendo otras
transacciones.

Bloqueo ordenado puede ayudar a evitar deadlocks.
Por ejemplo, supongamos que T1 y T2 bloquean
A y B en ese orden (alfabético) de forma exclusiva.
Si T1 y T2 están en deadlock, significará que T1
bloqueó A, T2 bloqueó B y T1 y T2 esperan B y A
respectivamente (o viceversa). Pero esto viola el
bloqueo ordenado; de hecho, los bloqueos cruzados
son imposibles porque una transacción violaría el
orden de bloqueo. Esto sigue siendo válido cuando
el deadlock ocurre en anillos de varias transa-
cciones (cena de filósofos).

Pero la cosa se complica con distintos niveles de
granularidad. Por ejemplo, bloquear una tabla
contra bloquear un atributo. Una solución es obviar
la granularidad; por ejemplo, bloquear una tabla
es lo mismo que bloquear sus átomos. Pero esto trae
problemas a la eficiencia...


6.- Serializabilidad de los planes

b) No es serializable por conflicto ni vista.
Grafo de conflictos:

            [T1]<----------[T2]
             |               ^
             |               |
              \_____________/

En el caso de vista, hay que comparar con T1.T2
y con T2.T1. Pero, no hay equivalencia con
alguno de estos casos.

d) El plan es serial. Luego, es serializable por
conflicto y vista.

f) Es serializable por conflicto, luego por vista.

             [T1]<-----------[T2]

             [T3]<-----------[T4]


7.- Organizar con 2PL básico y estricto, atendiendo
lo más rápido posible en promedio.

b) Básico y estricto llevan a planes seriales...

d) Básico y estricto llevan a planes seriales...

f) Estricto es serial (no hay planes sin variables
comunes). Pero 2PL básico no lo es:

       T1  |  T2  |  T3  |  T4
     ------+------+------+------
                    Lx(C)
                    Lx(D)
                    R(C)
                    R(D)
                    W(C)
                    U(C)
      Ls(A)
      Lx(B)
      Lx(C)
                    W(D)
                    U(D)
      R(A)
      U(A)
                           Lx(A)
                           Ls(E)
                           Lx(D)
                           R(A)
      R(B)
      R(C)
      W(B)
      U(B)
      W(C)
      U(C)
                           R(E)
                           W(A)
                           U(A)
                           W(D)
                           U(D)
             Ls(A)
             Lx(B)
             Ls(C)
             Lx(D)
             R(A)
                           U(E)
             R(B)
             R(C)
             W(B)
             W(C)
             U(A)
             U(B)
             U(C)
             U(D)


8.- Buscar deadlocks... Este ejercicio es
demasiado fácil.

b) Vemos que hay una transacción R(D),W(A)
y otra R(A),W(D). Éstas se pueden bloquear
mutuamente, ya que tienen bloqueos compartidos
y exclusivos sobre A y D, siendo uno la
viceversa del otro.
Ej.
         Ls(D)
                      Ls(A)
         Lx(A)!!!
                      Lx(D)!!!

f) ¡Esta no provoca deadlock! Pudiera parecer,
pero no hay ciclo de bloqueos como para hacer
una cena de filósofos (deadlock en anillo).


9.- Ver la relación de equivalencia entre los
planes (schedules) S y S', y ver la serializa-
bilidad de cada una.
Notación:
 =c : equivalencia por conflicto
 =v : equivalencia por vista
Ojo que: (A =c B) => (A =v B), no al revés.

b) { S =c K =v K' =c K }=> S =v S'
No se puede determinar la serializabilidad
de S ni de S'.

d) S =c S', serializables por conflicto.
Más aún, S y S' no presentan conflictos.
Demostración: sean N y M dos planes seriales
tal que N es el inverso de M (en transacciones),
e incumben 2 ó más transacciones (una transacción
es el caso trivial). S =c N y S =c M, ¿no? Pues
es equivalente a todo serial. Luego, N y M son
equivalentes por conflicto. Por ende, si hay un
arco en el grafo de conflictos de N, el arco
aparece en el grafo de M. ¡Pero debería
aparecer al revés! ¡Pero si aparece de ambas
maneras aparece un ciclo! Y eso no es posible
por la condición de seriales. Luego, NO HAY
ARCOS. O sea, NO HAY CONFLICTOS ENTRE TRANSA-
CCIONES. Pueden leer los mismos atributos,
pero no pueden escribir en un atributo que
otra transacción lee o escribe. []

f) S es serializable por conflicto.
S' es serializable por vista.
Obviamente, S y S' no son comparables.

h) Se subentiende que S y S' tratan de
distintas transacciones. Supongamos que S
no es serializable por conflicto. Entonces,
su grafo tiene un ciclo. Como T incluye S,
el ciclo de S debe aparecer en T. Pero como
T es serializable por conflicto, no tiene
ciclos. Luego, S no tiene ciclos. Lo mismo
aplica a S', por simetría. Por ende, S y S'
son serializables por conflicto, ya que
tienen grafos acíclicos. []
Obviamente, S y S' no son comparables.


14.- Planes recuperables:

a) Recuperable. Ninguno lee atributos sobre
los que no se ha hecho commit. (Suponiendo
que lo que había antes tuvo checkpoint.)

b) No recuperable. T1 lee de T3 el valor B,
sin que T3 hiciera commit. (Para remate, T3
aborta.)

c) Recuperable. Ninguna transacción lee datos
escritos por transacciones que no han hecho
commit.