Unidad 5 Transacciones distribuidas

Un sistema de informacin permite que los usuarios almacenen, accedan y modifiquen datos de
manera transparente desde o hacia diversas computadoras, manteniendo la integridad de los
datos durante alguna falla. Dada la naturaleza de una consulta, de lectura o actualizacin, a veces
simplemente no se puede reactivar su ejecucin, puesto que algunos datos pueden haber sido
modificados antes de un error. El no tomar en cuenta estos factores puede proporcionar que la
informacin en las bases de datos del sistema sea incoherente.

Un sistema transaccional es aquel que asegura que una unidad de trabajo se realice
completamente o que no tenga efecto. El manejo de transacciones libre al programador de la
responsabilidad de ocuparse del acceso a datos, incluye modificaciones concurrentes en los datos,
tolerancia a fallas y programacin multiusuario.

Las transacciones distribuidas son ms complejas que las transaccionales no distribuidas debido al
estado latente de que alguno de los manejadores falle y con ello el sistema global no opere de
manera correcta. En una red, una transaccin fallida puede ser difcil distinguir de una que es
simplemente lenta. Los manejadores locales de las bases de datos involucrados en una transaccin
no conocen el estado en que se encuentra el resto de los manejadores con los que cooperan y, por
lo tanto, no pueden coordinar sus propias transacciones de manera independiente.

Un manejador de base de datos es un sistema que brinda servicios a diferentes aplicaciones para
que estas puedan acceder a una base de datos. El manejador de base de datos brinda y hace
cumplir las propiedades ACID para operaciones que sobre l se ejecuten. Algunos de estos
manejadores podran proveer acceso a una base de datos relacional, brindando soporte de
almacenamiento de datos a una cierta aplicacin.

5.1 Transacciones.

Un sistema transaccional es un grupo de sentencias que representan una unidad de trabajo y
deben ejecutarse en su totalidad. Las transacciones son secuencias de operaciones lectura,
escrituras o actualizaciones- que llevan a un sistema de un estado consistente a otro. Se dice que
una base de datos se encuentra en un estado consistente si obedece a todas las restricciones de
integridad definida sobre ella.

Por ejemplo, si deseramos implementar una trasferencia de fondos entre dos cuentas bancarias
de un mismo cliente, podramos realizar dos operaciones:
Realizar un retiro de la cuenta A
Realizar un deposito en la cuanta B

Si la primera operacin es ejecutada entonces la segunda operacin debe ejecutarse
correctamente, viceversa. Si solo la primera operacin se realizara, el monto retirado de la cuenta
A nunca se habra depositado en la cuenta B, afectando negativamente el saldo la cuenta A de
nuestro cliente. De manera contraria, si solo se realizara la segunda operacin, nuestro cliente se
vera beneficiado al ver incremento su saldo en la cuenta B, pero afectando a la institucin
bancaria encargada de realizar dicha trasferencia, pues el monto depositado no provendra del
cliente que solicito la operacin.

En este caso, es necesario implementar una transaccin que involucre las operaciones de retiro y
depsito para asegurar que ambas se ejecuten en su totalidad o que ninguna de las dos sufra
efecto.

Commit

Una transaccin siempre termina, aun en la presencia de fallas. Si ninguna de las operaciones
englobadas por una transaccin representa una falla se dice que la transaccin es exitosa. En este
caso, la transaccin hace efectiva las modificaciones realizadas por las operaciones que involucra,
llevando el sistema a un nuevo estado consistente. A este proceso se le conoce como hacer un
commit.

Rollback

Si existe por lo menos una falla dentro de las operaciones de una transaccin, se dice que esta
abortada. Su ejecucin es detenida es detenida y todas las operaciones ejecutadas hasta en
momento del error son deshechas, regresando la base de datos al estado consistente en que se
entraba antes de iniciar la transaccin. A esta operacin se le conoce como hacer un rollback.



5.1.1 Estructura de transacciones.


La estructura de una transaccin usualmente viene dada segn el modelo de la transaccin, estas
pueden ser planas (simples) o anidadas.

Transacciones planas:
Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y
END. Por ejemplo:

BEGIN _TRANSACTION Reservacin
....
END.

Transacciones Anidadas:
Consiste en tener transacciones que dependen de otras, estas transacciones estn incluidas
dentro de otras de un nivel superior y se las conoce como subtransacciones. La transaccin de
nivel superior puede producir hijos (subtransacciones) que hagan ms fcil la programacin del
sistema y mejoras del desempeo.

En las transacciones anidadas las operaciones de una transaccin pueden ser as mismo otras
transacciones. Por ejemplo:

BEGIN _TRANSACTION Reservacin
..........
BEGIN _TRANSACTION Vuelo
........
END.( Vuelo ) ......
BEGIN _TRANSACTION Hotel
........
END
......
END.

Una transaccin anidada dentro de otra conserva las mismas propiedades que las de su padre,
esto implica, que puede contener as mismo transacciones dentro de ella.

Existen restricciones obvias en una transaccin anidada: debe empezar despus que su padre y
debe terminar antes que l. El compromiso de una subtransaccion es condicional al compromiso
de su padre, si el padre de una o varias subtransacciones aborta, las subtransacciones hijas
tambin sern abortadas.

Las transacciones anidadas brindan un nivel ms alto de concurrencia entre transacciones. Ya que
una transaccin consiste de varias transacciones es posible tener mayor concurrencia dentro de
una sola transaccin.

As tambin, es posible recuperarse de fallas de forma independiente de cada subtransaccion. Esto
limita el dao a una parte ms pequea de la transaccin, haciendo que el costo de la
recuperacin sea el menor.

Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y
escritura pueden ser mezcladas sin ninguna restriccin, entonces, a este tipo de transacciones se
les conoce como Generales.

Por el contrario, si se restringe o impone que un dato debe ser ledo antes de que pueda ser
escrito entonces se tendrn transacciones Restringidas.

Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las
acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de
accin para transacciones restringidas en donde se aplica an ms la restriccin de que cada par <
read , write > tiene que ser ejecutado de manera atmica.


5.1.2 Ejecucin de transacciones centralizada y distribuida.

Transacciones distribuidas abarcan dos o ms servidores conocidos como administradores de
recursos. La administracin de la transaccin debe ser coordinada entre los administradores de
recursos mediante un componente de servidor llamado administrador de transacciones. Cada
instancia de SQL Server Database Engine (Motor de base de datos de SQL Server) puede funcionar
como administrador de recursos en las transacciones distribuidas que coordinan los
administradores de transacciones, comoelCoordinador de transacciones distribuidas de Microsoft
(MS DTC) u otrosadministradores que admitan la especificacin Open Group XA del procesamiento
de transacciones distribuidas Una transaccin de una sola instancia de Database Engine (Motor de
base de datos) que abarque dos o ms bases de datos es, de hecho, una transaccin distribuida. La
instancia administra la transaccin distribuida internamente; para el usuario funciona como una
transaccin local .En la aplicacin, una transaccin distribuida se administra de forma muy
parecida a una transaccin local. Al final de la transaccin, la aplicacin pide que se confirme o
serevierta la transaccin. El administrador de transacciones debe administrar unaconfirmacin
distribuida de forma diferente para reducir al mnimo el riesgo de que,sie produce un error en la
red, algunos administradores de recursos realicenconfirmaciones mientras los dems revierten la
transaccin. Esto se consigue mediante la administracin del proceso de confirmacin en dos fases
(la fase de preparacin y la fase de confirmacin), que se conoce como confirmacin en dos fases
(2PC).
Fase de preparacin
Cuando el administrador de transacciones recibe una solicitud de confirmacin ,enva un comando
de preparacin a todos los administradores de recursos implicados en la transaccin. Cada
administrador de recursos hace lo necesario para que la transaccin sea duradera y todos los
bferes que contienen imgenes del registro de la transaccin se pasan a disco. A medida que
cada administrador de recursos completa la fase de preparacin, notifica si la preparacin ha
tenido xito o no al administrador de transacciones
Fase de confirmacin
Si el administrador de transacciones recibe la notificacin de que todas las preparaciones son
correctas por parte de todos los administradores de recursos ,enva comandos de confirmacin a
cada administrador de recursos. A continuacin, los administradores de recursos pueden
completar la confirmacin. Si todos los administradores de recursos indican que la confirmacin
ha sido correcta, el administrador de transacciones enva una notificacin de xito a la aplicacin.
Si algn administrador de recursos inform de un error al realizar la preparacin, el administrador
de transacciones enva un comando para revertir la transaccin a cada administrador de recursos
e indica ala aplicacin que se ha producido un error de confirmacin .Las aplicaciones de Database
Engine (Motor de base de datos) pueden administrar transacciones distribuidas a travs de
Transact-SQL o de la API de base de datos


5.2 Control de concurrencia.

Cuando se ejecutan varias transacciones concurrentemente en la base de datos, puede que deje
de conservarse la propiedad de aislamiento. Es necesario que el sistema controle la interaccin
entre las transacciones concurrentes; dicho control se lleva a cabo a travs de uno de los muchos
mecanismos existentes llamado esquemas de control de concurrencia.

5.2.2 Serializacin de transacciones.

Una calendarizacin (schedule), tambin llamado una historia, se define sobre un conjunto de
transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la ejecucin de las
operaciones de las transacciones. La calendarizacin puede ser especificada como un orden parcial
sobre T.

Ejemplo 6.1. Considere las siguientes tres transacciones:

T1: Read( x ) T2: Write( x ) T3: Read( x )
Write( x ) Write( y ) Read( y )
Commit Read( z ) Read( z )
Commit Commit

Una calendarizacin de las acciones de las tres transacciones anteriores puede ser:

H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }
Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el mismo dato de la
base de datos x se dice que estn en conflicto si al menos una de ellas es una escritura. De esta
manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos
tipos de conflictos read-write (o write-read) y write-write. Las dos operaciones en conflicto
pueden pertenecer a la misma transaccin o a transacciones diferentes. En el ltimo caso, se dice
que las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto entre dos
operaciones indica que su orden de ejecucin es importante. El orden de dos operaciones de
lectura es insignificante.
Una calendarizacin completa define el orden de ejecucin de todas las operaciones en su
dominio. Formalmente, una calendarizacin completa STc definido sobre un conjunto de
transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { T, <T } en donde

1. T = i i , para todos los i = 1, 2, ..., n
2. <T i <i , para todos los i = 1, 2, ..., n
3. Para cualesquiera dos operaciones en conflicto Oij y Okl T, Oij <T Okl
Okl <T Oij

La primera condicin establece simplemente que el dominio de la calendarizacin es la unin de
los dominios de las transacciones individuales. La segunda condicin define la relacin de
ordenamiento como un superconjunto de la relacin de ordenamiento de transacciones
individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transaccin. La
condicin final define el orden de ejecucin entre dos operaciones en conflicto.
Ejemplo 6.2. Considere las tres transacciones del Ejemplo 6.1, una posible calendarizacin
completa est dada por la siguiente grfica dirigida acclica (DAG).


Una calendarizacin se define como un prefijo de una calendarizacin completa. Un prefijo de un
orden parcial se define como sigue. Dado un orden parcial P = { , < }, P = { , < }, es un prefijo
de P si

1. i
2. ei , e1 < e2, si y solamente si, e1 < e2, y
3. ei , si ej y ej < ei, entonces, ej

Las primeras dos condiciones definen a P como una restriccin de P en el dominio , en donde
las relaciones de ordenamiento en P se mantienen por P. La ltima condicin indica que para
cualquier elemento de , todos sus predecesores en deben ser incluidos tambin en .
Ejemplo 6.3. La siguiente calendarizacin es un prefijo de la calendarizacin del Ejemplo 6.2.
Si en una calendarizacin S, las operaciones de varias transacciones no estn entrelazadas, esto es,
si las operaciones de una transaccin ocurren de manera consecutiva, entonces se dice que la
calendarizacin es serial. Si cada transaccin es consistente (obedece las reglas de integridad),
entonces la base de datos se garantiza ser consistente al final de la calendarizacin serial. La
historia asociada a este tipo de calendarizacin se le conoce como serial.
Ejemplo 6.4. La siguiente es una historia serial para el Ejemplo 6.1.
HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 }
Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia resultante
sobre la base de datos es equivalente a alguna historia serial. Bassada en la relacin de
precedencia introducida por el orden parcial, es posible discutir la equivalencia de diferentes
calendarizaciones con respecto a sus efectos sobre la base de datos.
Dos calendarizaciones, S1 y S2, definidas sobre el mismo conjunto de transacciones T, se dice que
son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i k), cada vez que Oij <1
Okl, entonces, Oij <2 Okl. A esta relacin se le conoce como equivalencia de conflictos puesto que
define la equivalencia de dos calendarizaciones en trmino del orden de ejecucin relativo de las
operaciones en conflicto en ellas.
Una calendarizacin S se dice que es serializable, si y solamente si, es equivalente por conflictos a
una calendarizacin serial.
Ejemplo 6.5. Las siguientes calendarizaciones no son equivalentes por conflicto:

HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 }
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }
Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H2 es serializable:
HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 }
H2 = { W2(x), R1(x), W1(x), C1, R3(x), W2(y), R3(y), R2(z), C2, R3(z), C3 }
La funcin primaria de un controlador de concurrencia es generar una calendarizacin serializable
para la ejecucin de todas las transacciones. El problema es, entonces, desarrollar algoritmos que
garanticen que nicamente se generan calendarizaciones serializables.


5.2.2 Algoritmos de control de concurrencia.


Los algoritmos de control de concurrencia deben sincronizar la ejecucin de transacciones
concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza
mediante el aislamiento de las mismas.

El criterio de clasificacin ms comn de los algoritmos de control de concurrencia es el
tipo de primitiva de sincronizacin. Esto resulta en dos clases: aquellos algoritmos que
estn basados en acceso mutuamente exclusivo a datos compartidos (candados) y
aquellos que intentar ordenar la ejecucin de las transacciones de acuerdo a un conjunto
de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con
dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas
transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no
se presentan muchos conflictos entre transacciones.
Los algoritmos pesimistas sincronican la ejecucin concurrente de las transacciones en su
etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan la sincronizacin
de las transacciones hasta su terminacin. El grupo de algoritmos pesimistas consiste de
algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de
tiempo y algoritmos hbridos. El grupo de los algoritmos optimistas se clasifican por
basados en candados y basados en estampas de tiempo.




5.2.2.1 Basados en bloqueo.

Una forma de asegurar la secuencialidad es exigir que el acceso a los elementos de datos se haga
en exclusin mutua; es decir, mientras una transaccin accede a un elemento de datos, ninguna
otra transaccin puede modificar dicho elemento. El mtodo ms habitual que se usa para
implementar este requisito es permitir que una transaccin acceda a un elemento de datos slo si
posee actualmente un bloqueo sobre dicho elemento.


Existen muchos modos mediante los cuales se puede bloquear un elemento de datos. En este
apartado se centra la atencin en dos de dichos modos:
1. Compartido. Si una transaccin T obtiene un bloqueo en modo compartido (denotado por C)
sobre el elemento Q, entonces T puede leer Q pero no lo puede escribir.
2. Exclusivo. Si una transaccin T obtiene un bloqueo en modo exclusivo (denotado por X) sobre
el elemento Q, entonces Ti puede tanto leer como escribir Q.
Es necesario que toda transaccin solicite un bloqueo del modo apropiado sobre el elemento de
datos Q dependiendo de los tipos de operaciones que se vayan a realizar sobre Q. La peticin se
hace al gestor de control de concurrencia. La transaccin puede realizar la operacin slo despus
de que el gestor de control de concurrencia conceda el bloqueo a la transaccin.
Dado un conjunto de modos de bloqueo, se puede definir sobre ellos una funcin de
compatibilidad como sigue. Utilizamos A y B para representar dos modos de bloqueo arbitrarios.
Supngase que la transaccin Ti solicita un bloqueo en modo A sobre el elemento Q, en el que la
transaccin Tj (Ti Tj) posee actualmente un bloqueo de modo B. Si a la transaccin Ti se le puede
conceder un bloqueo sobre Q a pesar de la presencia del bloqueo de modo B, entonces se dice
que el modo A es compatible con el modo B. Tal funcin se puede representar convenientemente
en forma de matriz. La relacin de compatibilidad entre los dos modos de bloqueoque se usan en
este apartado se presenta en la matriz comp de la Figura 16.1. Un elemento comp(A, B) de
lamatriz tiene el valor cierto si y slo si el modo A es compatible con el modo B.

FIGURA 16.1. Matriz de compatibilidad de bloqueo comp.

En sistemas basados en candados, el despachador es un administrador de candados (LM).
El administrador de transacciones le pasa al administrador de candados la operacin sobre la base
de datos (lectura o escritura) e informacin asociada, como por ejemplo el elemento de datos que
es accesado y el identificador de la transaccin que est enviando la operacin a la base de datos.
El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido
bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato
est bloqueado, entonces, la transaccin solicitante es retrasada. De otra forma, el candado se
define sobre el dato en el modo deseado y la operacin a la base de datos es transferida al
procesador de datos. El administrador de transacciones es informado luego sobre el resultado de
la operacin. La terminacin de una transaccin libera todos los candados y se puede iniciar otra
transaccin que estaba esperando el acceso al mismo dato.
Candados de dos fases (2PL)

En los candados de dos fases una transaccin le pone un candado a un objeto antes de
usarlo. Cuando un objeto es bloqueado con un candado por otra transaccin, la
transaccin solicitante debe esperar. Cuando una transaccin libera un candado, ya no
puede solicitar ms candados. As una transaccin que utiliza candados de dos fases se
comporta como en la Figura 6.2. En la primera fase solicita y adquiere todos los candados
sobre los elementos que va a utilizar y en la segunda fase libera los candados obtenidos
uno por uno.
La importancia de los candados de dos fases es que se ha demostrado de manera terica
que todos las calendarizaciones generadas por algoritmos de control de concurrencia que
obedecen a los candados de dos fases son serializables.
Puede suceder que si una transaccin aborta despus de liberar un candado, otras
transacciones que hayan accesado el mismo elemento de datos aborten tambin
provocando lo que se conoce como abortos en cascada. Para evitar lo anterior, los
despachadores para candados de dos fases implementan lo que se conoce como los
candados estrictos de dos fases en los cuales se liberan todos los candados juntos
cuando la transaccin termina (con commit o aborta). El comportamiento anterior se
muestra en la Figura 6.3.


Figura 6.2. Grfica del uso de los candados de dos fases.


Figura 6.3. Comportamiento de los candados de dos fases estrictos


5.2.2.2 Basados en estampas de tiempo.

A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas
de tiempo no pretenden mantener la seriabilidad por exclusin mutua. En lugar de eso,
ellos seleccionan un orden de serializacin a priori y ejecutan las transacciones de
acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le
asigna a cada transaccin Ti una estampa de tiempo nica ts( Ti ) cuando sta inicia. Una
estampa de tiempo es un identificador simple que sirve para identificar cada transaccin
de manera nica. Otra propiedad de las estampas de tiempo es la monoticidad, esto es,
dos estampas de tiempo generadas por el mismo administrador de transacciones deben
ser monotonicamente crecientes. As, las estampas de tiempo son valores derivados de
un dominio totalmente ordenado.


Figura 6.5. Comunicacin en candados de dos fases distribuidos.

Existen varias formas en que las estampas de tiempo se pueden asignar. Un mtodo es
usar un contador global monotonicamente creciente. Sin embargo, el mantenimiento de
contadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferible
que cada nodo asigne de manera autnoma las estampas de tiempos basndose en un
contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio
identificador. As, la estampa de tiempo es un par de la forma

<contador local, identificador de nodo>

Note que el identificador de nodo se agrega en la posicin menos significativa, de manera
que, ste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador
local a dos transacciones diferentes.

El administrador de transacciones asigna tambin una estampa de tiempo a todas las
operaciones solicitadas por una transaccin. Ms an, a cada elemento de datos x se le
asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de lectura,
rts(x); sus valores indican la estampa de tiempo ms grande para cualquier lectura y
escritura de x, respectivamente.

El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla:

Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las
transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y
solamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser un transaccin ms vieja y
Tk se dice ser una transaccin ms joven.

Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma:

for Ri(x) do begin
if ts(Ti) < wts( x ) then
reject Ri(x)
for Wi(x) do begin
if ts(Ti) < rts(x) and
ts(Ti) < wts(x) then
else
accept Ri(x)
rts(x) ts(Ti)
end
reject Wi(x)
else
accept Wi(x)
wts(x) ts(Ti)
end


La accin de rechazar una operacin, significa que la transaccin que la envi necesita
reiniciarse para obtener la estampa de tiempo ms reciente del dato e intentar hacer
nuevamente la operacin sobre el dato.
Ordenamiento conservador por estampas de tiempo

El ordenamiento bsico por estampas de tiempo trata de ejecutar una operacin tan
pronto como se recibe una operacin. As, la ejecucin de las operaciones es progresiva
pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador
de estampas de tiempo retrasa cada operacin hasta que exista la seguridad de que no
ser reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operacin
con una estampa de tiempo menor puede llegar al despachador. Un problema que se
puede presentar al retrasar las operaciones es que sto puede inducir la creacin de
interbloqueos (deadlocks).

Ordenamiento por estampas de tiempo mltiples

Para prevenir la formacin de interbloqueos se puede seguir la estrategia siguiente. Al
hacer una operacin de escritura, no se modifican los valores actuales sino se crean
nuevos valores. As, puede haber copias mltiples de un dato. Para crear copias nicas
se siguen las siguientes estrategias de acuerdo al tipo de operacin de que se trate:

1. Una operacin de lectura Ri(x) se traduce a una operacin de lectura de x de una
sola versin encontrando la versin de x, digamos xv, tal que, ts(xv) es la estampa
de tiempo ms grande que tiene un valor menor a ts(Ti).
2. Una operacin de escritura Wi(x) se traduce en una sola version, Wi(xw), y es
aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que,

ts(Ti) < ts(xr) < ts(Tj)

5.2.2.3 Pruebas de validacin optimistas.
Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas.
En otras palabras, ellos asumen que los conflictos entre transacciones son muy
frecuentes y no permiten el acceso a un dato si existe una transaccin conflictiva que
acceso el mismo dato. As, la ejecucin de cualquier operacin de una transaccin sigue
la secuencia de fases: validacin(V), lectura (R), cmputo (C) y escritura (W). Los
algoritmos optimistas, por otra parte, retrasan la fase de validacin justo antes de la fase
de escritura. De esta manera, una operacin sometida a un despachador optimista nunca
es retrasada. Las operaciones de lectura, cmputo y escrita de cada transaccin se
procesan libremente sin actualizar la base de datos corriente. Cada transaccin inicial
mente hace sus cambios en copias locales de los datos. La fase de validacin consiste en
verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la
respuesta es positiva, los cambios se hacen globales (escritos en la base de datos
corriente). De otra manera, la transaccin es abortada y tiene que reiniciar.

Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente
con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las
estampas de tiempo se asocian nicamente con las transacciones, no con los datos. Ms
an, las estampas de tiempo no se asignan al inicio de una transaccin sino justamente al
inicio de su fase de validacin. Esto se debe a que las estampas se requieren nicamente
durante la fase de validacin .Cada transaccin Ti se subdivide en varias
subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij
una subtransaccin deTi que se ejecuta en el nodo j. Supongamos que las transacciones
se ejecutan de manera independiente y ellas alcanzan el fin de sus fases de lectura. A
todas las subtransacciones se les asigna una estampa de tiempo al final de su fase de
lectura. Durante la fase de validacin se realiza una prueba de validacin, si una
transaccin falla, todas las transacciones se rechazan
La prueba de validacin se realiza con una de las siguientes reglas:
1. Si todas las transacciones Tk , tales que ,ts (Tk ) <ts Tij ), han terminado su fase
de escritura antes que Tij ha iniciado su fase de lectura entonces la validacin
tiene xito. En este caso la ejecucin de las transacciones es completamente
serial como se muestra en la Figura 6.7
2. .2. Si existe alguna transaccin Tk , tal que, ts ( Tk ) < ts (Tij ) y la cual completa su
fase de escritura mientras Tij est en su fase de lectura, entonces, la validacin
tiene xito si WS ( Tk ) RS ( Tij ) = . En este caso, las fases de lectura y
escritura se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos
que son escritos por Tk .
3. Si existe alguna transaccin Tk , tal que, ts ( Tk ) < ts (Tij ) y la cual completa su
fase de lectura antes que Tij termine su fase de lectura, entonces, la validacin
tiene xito si WS ( Tk ) RS ( Tij ) = y WS ( Tk ) WS (Tij ) = . En este
caso, las fases de lectura se traslapan, como se muestra en la Figura 2, pero las
transacciones no accedan datos comunes.


5.2.3 Disciplinas del Interbloqueo: prevencin, deteccin,
eliminacin y recuperacin.
Un interbloqueo se produce cuando dos o ms tareas se bloquean entre s
permanentemente teniendo cada tarea un bloqueo en un recurso que las otras tareas
intentan bloquear.
Un interbloqueo es una condicin que se puede dar en cualquier sistema con varios
subprocesos, no slo en un sistema de administracin de bases de datos relacionales, y
puede producirse para recursos distintos a los bloqueos en objetos de base de datos
Por ejemplo:
La transaccin A tiene un bloqueo compartido de la fila 1.
La transaccin B tiene un bloqueo compartido de la fila 2.
La transaccin A ahora solicita un bloqueo exclusivo de la fila 2 y se bloquea hasta que la
transaccin B finalice y libere el bloqueo compartido que tiene de la fila 2.
La transaccin B ahora solicita un bloqueo exclusivo de la fila 1 y se bloquea hasta que la
transaccin A finalice y libere el bloqueo compartido que tiene de la fila 1.

Prevencin del interbloqueo.
Objetivo: conseguir que sea imposible la aparicin de situaciones de interbloqueo.
Impedir que se produzca una de las cuatro condiciones necesarias para producirlo:
Exclusin mutua, Retencin y espera, No expropiacin, y Espera circular.
Condicionar un sistema para quitar cualquier posibilidad de ocurrencia de
interbloqueo.
Que no se cumpla una condicin necesaria
Exclusin mutua y sin expropiacin no se pueden relajar. Dependen de carcter
intrnseco del recurso.
Las otras dos condiciones son ms prometedoras.
Recuperacin de Interbloqueo.
Limpiar un sistema de interbloqueos, una vez que fueron detectados.
Cuando se ha detectado que existe un interbloqueo, podemos actuar de varias formas.
Una posibilidad es informar al operador que ha ocurrido un interbloqueo y dejar que el
operador se ocupe de l manualmente. La otra posibilidad es dejar que el sistema se
recupere automticamente del interbloqueo. Dentro de esta recuperacin automtica
tenemos dos opciones para romper el interbloqueo: Una consiste en abortar uno o ms
procesos hasta romper la espera circular, y la segunda es apropiar algunos recursos de
uno o ms de los procesos bloqueados.
Eliminar interbloqueos.
Para eliminar interbloqueos abortando un proceso, tenemos dos mtodos; en ambos, el
sistema recupera todos los recursos asignados a los procesos terminados.
Abortar todos los procesos interbloqueados. Esta es una de las soluciones ms comunes,
adoptada por Sistemas Operativos. Este mtodo romper definitivamente el ciclo de
interbloqueo pero con un costo muy elevado, ya que estos procesos efectuaron clculos
durante mucho tiempo y habr que descartar los resultados de estos clculos parciales,
para quiz tener que volver a calcularlos ms tarde.
Abortar un proceso en cada ocasin hasta eliminar el ciclo de interbloqueo. El orden en
que se seleccionan los procesos para abortarlos debe basarse en algn criterio de costo
mnimo. Despus de cada aborto, debe solicitarse de nuevo el algoritmo de deteccin,
para ver si todava existe el interbloqueo. Este mtodo cae en mucho tiempo de
procesamiento adicional.

Si ste se encuentra actualizando un archivo, cortarlo a la mitad de la operacin puede
ocasionar que el archivo quede en un mal estado.
Si se utiliza el mtodo de terminacin parcial, entonces, dado un conjunto de procesos
bloqueados, debemos determinar cul proceso o procesos debe terminarse para intentar
romper el interbloqueo. Se trata sobre todo de una cuestin econmica, debemos abortar
los procesos que nos representen el menor costo posible.

5.3 Confiabilidad.
Un sistema de manejo de bases de datos confiable es aquel que puede continua
procesando las solicitudes de usuario aun cuando el sistema sobre el que opera no es
confiable. En otras palabras, aun cuando los componentes de un sistema distribuido
fallen, un DDMBS confiable debe seguir ejecutando las solicitudes de usuario sin violar la
consistencia de la base de datos.

5.3.1 Conceptos bsicos de confiabilidad.

A lo largo de estas notas nos hemos referido a la confiabilidad y disponibilidad de la base
de datos sin definir esos trminos de manera precisa. En esta seccin daremos sus
definiciones generales para posteriormente elaborarlas de manera ms formal. La
confiabilidad se puede interpretar de varias formas. La confiabilidad se puede ver como
una medida con la cual un sistema conforma su comportamiento a alguna especificacin.
Tambin se puede interpretar como la probabilidad de que un sistema no haya
experimentado ninguna falla dentro de un periodo de tiempo dado. La confiabilidad se
utiliza tpicamente como un criterio para describir sistemas que no pueden ser reparados
o donde la operacin continua del sistema es crtica.
Disponibilidad, por otro lado, es la fraccin del tiempo que un sistema satisface su
especificacin. En otras palabras, la probabilidad de que el sistema sea operacional en un
instante dado de tiempo.

5.3.2 Protocolos REDO/UNDO.
El registro de la base de datos contiene informacin que es utilizada por el proceso de
recuperacin para restablecer la base de datos a un estado consistente. Esta informacin
puede incluir entre otras cosas:
El identificador de la transaccin,
El tipo de operacin realizada,
Los datos accesados por la transaccin para realizar la accin,
El valor anterior del dato (imagen anterior), y
El valor nuevo del dato (imagen nueva).
Considere el escenario mostrado en la Figura de abajo. El DBMS inicia la ejecucin en el
tiempo 0 y en el tiempo t se presenta una falla del sistema. Durante el periodo [0, t]
ocurren dos transacciones, T1 y T2. T1 ha sido concluida (ha realizado su commit) pero
T2 no pudo ser concluida.
La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la base de
datos estable. De forma similar, la propiedad de atomicidad requiere que la base de datos
estable no contenga alguno de los efectos de T2.
Ejemplo de una falla del sistema.
A pesar que T1 haya sido terminada, puede suceder que el buffer correspondiente a la
pgina de la base de datos modificada no haya sido escrito a la base de datos estable.
As, para este caso la recuperacin tiene que volver a realizar los cambios hechos por T1.
A esta operacin se le conoce como REDO y se presenta en la Figura de abajo.
La operacin de REDO utiliza la informacin del registro de la base de datos y realiza de
nuevo las acciones que pudieron haber sido realizadas antes de la falla. La operacin
REDO genera una nueva imagen.
Operacin REDO.
Por otra parte, es posible que el administrador del buffer haya realizado la escritura en la
base de datos estable de algunas de las pginas de la base de datos voltil
correspondientes a la transaccin T2.
As, la informacin de recuperacin debe incluir datos suficientes para permitir deshacer
ciertas actualizaciones en el nuevo estado de la base de datos y regrasarla al estado
anterior. A esta operacin se le conoce como UNDO y se muestra en la Figura de abajo.
La operacin UNDO restablece un dato a su imagen anterior utilizando la informacin del
registro de la base de datos.


Operacin UNDO.
De forma similar a la base de datos voltil, el registro de la base de datos se mantiene en
memoria principal (llamada los buffers de registro) y se escribe al almacenamiento estable
(llamadoregistro estable). Las pginas de registro se pueden escribir en el registro estable
de dos formas: sncrona o asncrona. En forma sncrona, tambin llamada un registro
forzado, la adicin de cada dato en el registro requiere que la pgina del registro
correspondiente se mueva al almacenamiento estable. De manera asncrona, las pginas
del registro se mueven en forma peridica o cuando los buffers se llenan.

5.3.3 Puntos de verificacin (checkpoints).
La operacin de recuperacin requiere recorrer todo el registro de la base de datos. As,
el buscar todas las transacciones a las cuales es necesario aplicarles un UNDO o REDO
puede tomar una cantidad de trabajo considerable. Para reducir este trabajo se pueden
poner puntos de verificacin (checkpoints) en el registro de la base de datos para indicar
que en esos puntos la base de datos est actualizada y consistente. En este caso, un
REDO tiene que iniciar desde un punto de verificacin y un UNDO tiene que regresar al
punto de verificacin ms inmediato anterior. La colocacin de puntos de verificacin se
realiza con las siguientes acciones:

Se escribe un "begin_checkpoint" en el registro de la base de datos.
Se recolectan todos los datos verificados en la base de datos estable.
Se escribe un "fin_de_checkpoint" en el registro de la base de datos.

5.3.4 Protocolo 2PC de confiabilidad distribuida.
El protocolo 2PC bsico un agente (un agente-DTM en el modelo) con un rol especial.
Este es llamado el coordinador; todos los dems agentes que deben hacer commit a la
vez son llamados participantes.
El coordinador es responsable de tomar la decisin de llevar a cabo un commit o abort
finalmente. Cada participante corresponde a una subtransaccin la cual ha realizado
alguna accin de escritura en su base de datos local.
Se puede asumir que cada participante est en un sitio diferente. Aun si un participante y
el coordinador se encuentran en el mismo sitio, se sigue el protocolo como si estuvieran
en distintos sitios.
La idea bsica del 2PC es determinar una decisin nica para todos los participantes con
respecto a hacer commit o abort en todas las subtransacciones locales.
El protocolo consiste en dos fases:
La primera fase tiene como objetivo alcanzar una decisin comn,
La meta de la segunda fase es implementar esta decisin.
El protocolo procede como sigue:
Fase uno:
El coordinador escribe prepare en la bitcora y enva un mensaje donde pregunta
a todos los participantes si preparan el commit (PREPARE).
Cada participante escribe ready (y registra las subtransacciones) en su propia
bitcora si est listo o abort de lo contrario.
Cada participante responde con un mensaje READY o ABORT al coordinador.
El coordinador decide el commit o abort en la transaccin como un resultado de
las respuestas que ha recibido de los participantes. Si todos respondieron READY,
decide hacer un commit. Si alguno ha respondido ABORT o no ha respondido en
un intervalo de tiempo determinado se aborta la transaccin.
Fase dos:
El coordinador registra la decisin tomada en almacenamiento estable; es decir,
escribe global_commit o global_abort en la bitcora.
El coordinador enva mensaje de COMMIT o ABORT segn sea el caso para su
ejecucin.
Todos los participantes escriben un commit o abort en la bitcora basados en el
mensaje recibido del coordinador (desde este momento el procedimiento de
recuperacin es capaz de asegurar que el efecto de la subtransaccin no ser
perdido).
Finalmente:
Todos los participantes envan un mensaje de acuse de recibo (ACK) al coordinador, y
ejecutan las acciones requeridas para terminar (commit) o abortar (abort) la
subtransaccin.
Cuando el coordinador ha recibido un mensaje ACK de todos los participantes, escribe un
nuevo tipo de registro en la bitcora, llamado un registro completo.