SISTEMAS DISTRIBUIDOS

TEMA 8.1: Transacciones y Control de Concurrencia

 1. Introducción
Una transacción define una secuencia de operaciones que se realizan por un servidor, y se
garantiza por el mismo que es atómica, ya sea en presencia de múltiples usuarios e incluso de
caídas del servidor. . Se utiliza el nemotécnico ACID (Atomicity, Consistency, Isolation, Durability)
para recordar las propiedades de las transacciones:

-Atomicidad. Una transacción debe ser todo o nada. En otras palabras, o finaliza
correctamente, y los efectos de todas sus operaciones son registrados, o si falla es
abortada y no tienen ningún efecto.

-Consistencia. Una transición hace pasar el sistema de un estado consistente a otro.

-Aislamiento. Los efectos intermedios o parciales de una transacción no deben ser

visibles para las demás.

-Durabilidad. Después de que una transacción ha finalizado con éxito, todos sus efectos
son guardados en un almacenamiento permanente, de forma que los datos guardados
sobrevivirán incluso en caso de ruptura del servidor.

En algunas situaciones, los clientes necesitan realizar una serie de invocaciones sobre un objeto
que deben ser atómicas en el sentido de:
1. Las invocaciones no interfieren con la actividad de otros clientes sobre el mismo
objeto.

2. Todas las invocaciones deber ser completadas con éxito o ninguna debe ejecutarse si
el servidor falla.

 2. Control de concurrencia
El objetivo de cualquier servidor que soporta transacciones es maximizar la concurrencia. Para
ello, se debe permitir que se ejecuten concurrentemente transacciones como si el efecto de
ellas fuera el mismo que si se ejecutaran secuencialmente, es decir, si fueran secuencialmente
equivalentes. Solo hay problemas en operaciones conflictivas, en las cuales el efecto
combinado depende del orden de ejecución.

A continuación, se muestran dos problemas de transacciones concurrentes: el problema de las

actualizaciones pérdidas y el problema de las lecturas inconsistentes.

 El problema de las actualizaciones pérdidas. Este problema se muestra mediante el

siguiente par de transacciones obre las cuentas bancarias A, B y C, cuyos balances
iniciales son 100$, 200$ y 300$ respectivamente. La transacción T transfiere cierta
cantidad desde la cuenta A hasta la cuenta B. La transacción U transfiere otra cantidad
desde la cuenta C hasta la B. En ambos casos, la cantidad transferida se calcula para
incrementar el balance de B en un 10%. Los efectos netos sobre la cuenta B al ejecutar

1
 las transacciones T y U debieran hacer incrementar el balance de la cuenta B en un 10%
dos veces, por lo que el valor final será 242$.
Consideremos ahora los efectos de permitir que las transacciones T y U se ejecuten
concurrentemente, como en la figura siguiente.

Ambas transacciones obtienen el balance de B como 200$ y después depositan 20$. El

resultado es incorrecto, al incrementar el balance de la cuenta B en 20$ en lugar de 42$.

Esto es un ejemplo del problema de las actualizaciones pérdidas. La actualización de U

se pierde porque T escribe sin mirar. Ambas transacciones han leído el valor previo antes
de escribir el nuevo valor.

 El problema de las lecturas inconsistentes. La siguiente figura muestra otro ejemplo

relacionado con una cuenta bancaria en el que la transacción V transfiere una suma
desde la cuenta A hasta la B y la transacción W invoca el método totalSucursal para
obtener la suma de los balances de todas las cuentas del banco. Los balances de las dos
cuentas bancarias, A y B son ambos inicialmente 200$. El resultado de totalSucursal
incluye la suma de A y B como 300$, que es incorrecto. Las lecturas de W son
inconsistentes porque V había realizado sólo la parte de extracción de su transferencia
mientras se calculaba la suma.

2
 2.1 Equivalencia secuencial.
El uso de la equivalencia secuencial como un criterio para la ejecución concurrente correcta
previene de la ocurrencia de actualizaciones pérdidas y lecturas inconsistentes.

 La actualización pérdida ocurren cuando una transacción utilizar un valor obsoleto para
fijar un nuevo estado. Esto se resuelve si la transacción U no accede al recurso hasta que
T haya terminado con él.

 La lectura inconsistente ocurre cuando una transacción de lectura y una de

actualización se ejecutan de forma concurrente. Se soluciona si la transacción de lectura
se realiza antes o después de una transacción de actualización.

2.2 Operaciones conflictivas.

Decimos que un par de operaciones tienen conflictos cuando su efecto combinado depende del
del orden el que se ejecutan. En la siguiente figura se dan las reglas de conflicto para las
operaciones de lectura y escritura.

- Lectura – Lectura tienen el mismo efecto sin importar el orden.

- Lectura – escritura tienen efecto distinto en función del orden.
- Escritura- escritura tienen efecto distinto en función del orden.

 3. Recuperabilidad de transacciones abortadas

Los servidores deben registrar los efectos de todas las transacciones finalizadas y ninguno de los
efectos de las transacciones abortadas. Por tanto, deben considerar el hecho de que una
transacción pueda ser abortada en previsión de que afecte a otras transacciones concurrentes.

Vamos a ver dos problemas asociados con las transacciones abortadas conocidos como lecturas
sucias y escrituras prematuras.

 Lecturas sucias. La propiedad de aislamiento de las transacciones requiere que éstas no

vean el estado no finalizado de las demás. El problema de la lectura sucia está causado
por la interacción entre una operación de lectura en una transacción y una operación
temprana de escritura en otra transacción sobre el mismo objeto.

Considere las trazas mostradas en la siguiente figura, donde T consigue el balance de la

cuenta A y le añade 10$ más. A continuación, U consigue el balance de A y le añade 20$
más. Las dos ejecuciones son secuencialmente equivalentes.
Supongamos ahora que la transacción T aborta después de que U ha finalizado. Entonces
la transacción U habrá visto un valor que jamás ha existido, puesto que se restaurará el
valor original en A. En este caso, se dice que la transacción U ha realizado una lectura
sucia, y como U ya ha finalizado no puede ser desecha.

3
 Si una transacción (como U) ha finalizado después de que visto los efectos de una
transacción que posteriormente ha sido abortada, la situación no es recuperable. Para
asegurar que tales situaciones no se plantean, cualquier transacción que esté en peligro
de tener una lectura sucia retrasa su commit hasta la terminación de todas las
transacciones cuyos efectos se hayan observado. Sin embargo, esto puede provocar
cascadas de aborts.

Para evitar las cascadas de aborts, solo se permite a las transacciones leer objetos que
fueron escritos por transacciones consumadas. Para asegurar que esto es así, debe
retrasarse cualquier operación de lectura hasta que haya sido comprometida o abortada
cualquier otra transacción que haya realizado una operación de escritura sobre el mismo
objeto.

La evitación de los abortos en cascadas es más importante que la recuperabilidad.

 Escrituras prematuras. Consideremos otra implicación de la posibilidad de que una

transacción pueda abortar relacionada con las interacciones entre operaciones de
escritura en el mismo objeto.
Como ejemplo, consideremos dos transacciones ponBalance T y U sobre la cuenta A,
como se muestra en la siguiente figura. Antes de las transacciones el balance de la
cuenta A era de 100$. Las dos ejecuciones son secuencialmente equivalentes, con T
poniendo el balance a 105$ y U a 110$. Si la transacción U aborta y T se compromete, el
balance debería ser 105$.

Algunos sistemas de bases de datos implementan la acción de abortar restableciendo

las “imágenes anteriores” de todas las escrituras de una transacción. En nuestro ejemplo
A, es 100$ inicialmente, que es la imagen anterior de la escritura de T; de forma similar,
105$ es la imagen anterior de la escritura de U. Por tanto, si U aborta conseguimos el
balance correcto de 105$.

4
 Ahora consideremos el caso de que U se compromete y después T aborta. El balance
debería estar a 110$, pero la “imagen anterior” de la escritura es 100$, por lo que
conseguimos el balance incorrecto de 100$. De forma similar, si T aborta y después U
aborta, la imagen anterior de la escritura de U es 105$, por lo que conseguimos el
balance erróneo de 105$, ya que el balance debería ser 100$.

Para garantizar los resultados correctos en un esquema de recuperación, las

operaciones de escritura deben ser retrasadas hasta que hayan sido comprometidas o
abortadas transacciones anteriores que actualizaron los mismos objetos.

Las ejecuciones de las transacciones se llaman escrituras escritas si el servicio de las

operaciones de lectura y escritura sobre un objeto se retrasa hasta que todas las
transacciones que previamente escribieron el objeto han sido comprometidas o
abortadas. La ejecución estricta de las transacciones hace cumplir la deseada
propiedad de aislamiento, pero reduce el paralelismo.

3.1 Versiones tentativas de objetos.

Para que un servidor de objetos participe en las transacciones, debe estar diseñado de forma
que las actualizaciones de los objetos puedan ser eliminadas cuando la transacción aborta. Para
hacer esto posible, todas las operaciones de actualización realizadas durante una transacción se
hacen sobre versiones provisionales de los objetos en memoria volátil. Las versiones
provisionales son escritas en el objeto real de forma persistente sólo cuando la transacción se
compromete. Cuando una transacción aborta, sus versiones provisionales se borran.

 4. Protocolos de Control de Concurrencia

Todos los protocolos de control de concurrencia están basados en el criterio de equivalencia
secuencial y se derivan de reglas para los conflictos entre operaciones. Se describen tres
métodos:

-Bloqueos. Se utilizan para ordenar transacciones que acceden a los mismos objetos de
acuerdo con el orden de llegada de sus operaciones sobre dichos objetos.

-Control optimista de concurrencia. Permite a las transacciones avanzar hasta que están
dispuestas para consumarse, que es cuando se realiza una comprobación para ver si se
han efectuado operaciones conflictivas con los objetos.
-Ordenación con marcas de tiempo. La ordenación por marca de tiempo utiliza dichas
marcas para ordenar las transacciones que acceden a los mismos objetos de acuerdo
con los instantes de comienzo.

5
 4.1 Bloqueos
Las transacciones deben planificarse de forma que sus efectos sobre datos compartidos sean
secuencialmente equivalentes. Un servidor puede conseguir la equivalencia secuencial de las
transacciones secuenciando el acceso a los objetos.

 Bloqueos exclusivos.

Un ejemplo sencillo de un mecanismo de secuenciación es el uso de bloqueos exclusivos. En este

esquema de bloqueo, el servidor intenta bloquear cualquier objeto que vaya a ser utilizado por
cualquier operación de la transacción de un cliente. Si un cliente solicita el acceso a un objeto
que ya está bloqueado por una transacción de otro cliente, la solicitud es suspendida y el cliente
debe esperar hasta que el objeto es desbloqueado.

La siguiente figura ilustra el uso de bloqueos exclusivos. En este ejemplo, se supone que cuando
las transacciones T y U comienzan los balances de las cuentas A, B y C no están todavía
bloqueados. Cuando la transacción T va a utilizar la cuenta B, B se bloquea para T.
Consecuentemente, cuando la transacción U va a utilizar B ésta está todavía bloqueada para T,
y la transacción U espera. Cuando se consuma la transacción T, B es desbloqueado, después de
lo cual se reanuda la transacción U. Hay que tener en cuenta que sí, por ejemplo, T ha liberado
el bloqueo en B entre sus operaciones obtenBalance y ponBalance, la operación obténBalance
de la transacción U puede solaparse entre ellas.

 Bloqueo en dos fases.

La equivalencia secuencial precisa que todos los accesos de una transacción a un objeto
particular sean secuenciados con respecto a los accesos por otras transacciones. Todos los pares
de operaciones conflictivas de dos transacciones deberían ser ejecutados en el mismo orden.
Para asegurar esto, no está permitido a una transacción ningún nuevo bloqueo después que
ha liberado uno. Este hecho delimita dos fases:

-Fase de crecimiento. Se adquieren nuevos bloqueos.

-Fase de reducción. Se liberan los bloqueos.

El inconveniente de los bloqueos en dos fases es que no previenen de lecturas sucias y escrituras
prematuras.

6
  Bloqueo estricto en dos fases.

Los bloqueos estrictos en dos fases son una extensión de los bloques en dos fases de forma que,
para hacer cumplir con las escrituras prematuras y lecturas sucias, se mantienen todos los
bloqueos aplicados durante el progreso de una transacción hasta que ésta se consuma o se
aborta.

Los bloqueos estrictos en dos fases garantizan la ejecución estricta:

-Previenen de lecturas sucias y escrituras prematuras.

-Reduce el paralelismo potencial.

 Interbloqueos.

Un interbloque es un estado en el que cada miembro de un grupo de transacciones está

esperando por algún otro miembro para liberar un bloqueo.

-Prevención de interbloqueos.

-Bloqueando todo al principio. Una forma aparentemente simple pero no muy

buena para vencer el interbloqueo es bloquear todos los objetos utilizados por
una transacción cuando comienza. Esta solución reduce considerablemente la
concurrencia.

-Adquiriendo/liberando bloqueos en orden. El bloqueo indefinido puede

también impedirse solicitando los bloqueos en los objetos en un orden
predefinido, pero esto puede producir una reducción de la concurrencia.

-Detección de bloqueos indefinidos.

-Búsqueda de ciclos en relación “espera a”. Los bloqueos indefinidos pueden

detectarse a través de los ciclos en el grafo espera por. Una vez detectado un
bloqueo indefinido, para romper el ciclo se debe seleccionar una transacción
para abortar. Sin embargo, la elección de la transacción a abortar es difícil.

-Timeouts. Los timeouts de bloqueo son un método para la resolución de

interbloqueos indefinidos que se utilizan normalmente, pero también son
problemáticos.

4.2 Control optimista de la concurrencia.

Kung y Robinson identificaron un número de desventajas inherentes al bloqueo y propusieron
una aproximación alternativa a la secuenciación de transacciones que evita esas desventajas.
Los problemas del uso de bloqueos son los siguientes:

-El mantenimiento de los bloqueos plantea una sobrecarga, incluso en las transacciones
sólo de lectura.

-El uso de bloqueos puede producir un interbloqueo y la prevención de interbloqueos

reduce la concurrencia de forma severa.

7
 -Para impedir abortos en cascada, los bloqueos no pueden ser liberados hasta el final de
la transacción. Esto puede reducir significativamente el potencial de concurrencia.
La aproximación alternativa propuesta por Kung y Robinson es optimista porque se basa en la
observación de que, en la mayoría de las aplicaciones, la probabilidad de que dos transacciones
concurrentes accedan al mismo objeto es baja.

Por este motivo, se permite que las transacciones procedan como si no hubiera posibilidad de
conflicto con otras transacciones hasta que el cliente complete su tarea y publique una petición
cierraTransacción. Cuando aparece un conflicto, habitualmente se abortará alguna transacción
y se necesitará reiniciar el cliente. Cada transacción se ejecuta en las siguientes tres fases.

-Fase de trabajo. Durante esta fase, cada transición tiene una versión tentativa de cada
uno de los objetos que actualiza. El empleo de las versiones tentativas permite a las
transacciones abortar, sin efecto ninguno sobre los objetos.

-Fase de validación. Cuando se recibe la solicitud cierraTransación, se valida la

transacción para establecer si sus operaciones en los objetos entran en conflicto o no
con las operaciones en otras transacciones sobre los mismos objetos.

-Fase de actualización. Si no hay conflictos se consuma. Las transacciones de sólo

lectura pueden consumarse inmediatamente después de pasar la validación.

4.3 Comparación de métodos para el control de concurrencia.

 Ordenación y bloqueo en dos fases son métodos pesimistas.

o Ordenación decide serialización estática, pero aborta de inmediato. Es mejor
cuando predominan transacciones de lectura.

o Bloqueos en dos fases decide serialización dinámicamente, pero hace esperar.

Es mejor cuando predominan transacciones de escritura.

 Control de concurrencia optimista. Es ideal cuando hay pocos conflictos, pero hay
que tener cuidado porque mucho trabajo puede ser hecho en balde.

8
TEMA 8.2: Transacciones distribuidas
 1. Introducción
Utilizamos el término de transacción distribuida para hacer referencia a una transacción que
accede a objetos gestionados por diferentes servidores.

-Cuando una transacción distribuida llega a su fin, la propiedad de atomicidad de la

transacción requiere que, todos los servidores involucrados completen la transacción o
que todos aborte la transacción. Para lograr esto, uno de los servidores asume el papel
de coordinador para asegurar el mismo resultado en todos los servidores. La forma en
la que el coordinador propaga la decisión es haciendo uso de un protocolo de
consumación.

-El control de concurrencia en transacciones distribuidas se basa en los métodos que

hemos visto anteriormente. Cada servidor aplica un control de concurrencia local sobre
sus propios objetos, lo que garantiza la secuenciación local de las transacciones.
Además, las transacciones distribuidas deben secuenciarse globalmente, lo cual se
consigue de una forma u otra dependiendo del método de serialización local.
-La recuperación de transacciones se preocupa de asegurar que sean recuperables
todos los objetos involucrados en una transacción. Además de esto, garantiza
aislamiento.

1.1 Transacciones planas y anidadas.

Una transacción de un cliente se hace distribuida si invoca operaciones en varios servidores.
Existen dos formas distintas en las que pueden estructurarse las transacciones distribuidas:
como transacciones planas y como transacciones anidadas.
 En una transacción plana, un cliente realiza peticiones a más de
un servidor. Por ejemplo, en la siguiente imagen, la transacción T
es una transacción plana que invoca operaciones en objetos de los
servidores X, Y y Z. Una transición cliente plana completa cada
petición antes de pasar a la siguiente. En consecuencia, cada
transacción accede secuencialmente a los objetos de los
servidores.

 En una transacción anidada, la transacción de nivel

superior puede abrir subtransacciones, y cada
subtransacción puede abrir subtransacciones mas
profundas hasta cualquier nivel de profundidad.
La siguiente figura muestra la transacción T de un cliente
que abre dos subtransacciones T1 y T2, que acceden a los
objetos en los servidores X e Y. Las subtransacciones T1 y T2
abren a su vez las subtransacciones T11, T12, T21 y T22, que
acceden a los objetos en los servidores M, N y P.
En el caso anidado, las subtransacciones del mismo nivel
pueden ejecutarse concurrentemente.

9
Como ejemplo considere una transacción distribuida en la cual un cliente transfiere diez dólares
desde una cuenta A a otra cuenta C, y después transfiere veinte dólares desde B hasta D. Las
cuentas A y B están en servidores separados X e Y, y las cuentas C y D, están en el servidor Z. Si
la transacción se estructura como un conjunto de cuatro transacciones anidadas, las cuatro
peticiones (dos depósitos y dos extracciones) pueden ejecutarse en paralelo, y el efecto global
puede conseguir con mejor rendimiento que el de una transacción simple en la que las cuatro
operaciones se invocan secuencialmente.

 2. El coordinador de una transacción distribuida.

Los servidores que ejecutan peticiones como parte de una transacción distribuida necesitan
poder comunicarse entre ellos para coordinar sus acciones cuando se compromete la
transacción. Un cliente comienza una transacción contactando con un coordinador. Puede
haber más de un coordinador, y por eso, el coordinador con el que se contacta lleva a cabo la
operación y devuelve al cliente el identificador resultante de la transacción (TID, server id + nº
de secuencia). Los identificadores de transacciones distribuidas han de ser únicos dentro del
sistema distribuido.

Cada uno de los servidores que gestione un objeto al que accede la transacción distribuida es un
participante en la transacción y proporciona un objeto que llamaremos participante. Cada
participante es responsable de seguir la pista de todos los objetos recuperables en el servidor
implicado en la transacción. Durante el progreso de una transacción, el coordinador registra una
lista de referencias de participantes, y cada participante registra una referencia hacia el
coordinador. El participante invoca join() del coordinador la primera vez. Además, cada
participante puede abortar la transacción.

10
  3. Protocolos de consumación.
Un protocolo de consumación atómica es un procedimiento utilizado por un conjunto de
servidores involucrados en una transacción distribuida, que permite que los servidores lleguen
a una decisión conjunta sobre si una transacción debe ser consumada (comprometida) o debe
ser abortada.

 Protocolo de consumación atómica en una fase. Una forma sencilla de completar la

transacción de una forma atómica es que el coordinador comunique, a todos los
participantes en la transacción, la petición de consumar o abortar, y continúe repitiendo
la petición hasta que todos ellos hayan enviado reconocimientos indicando que la han
llevado a cabo.
Este sencillo protocolo es inadecuado porque, en el caso de que el cliente solicita una
consumación, no permite a un servidor tomar una decisión unilateral de abortar la
transacción. Las razones que impiden que un servidor sea capaz de consumar su parte
de una transacción están relacionadas, generalmente, con temas de control de
concurrencia.

 Protocolo de consumación en dos fases. El protocolo de consumación en dos fases está

diseñado para permitir que cualquier participante pueda abortar su parte de la
transacción, pero debido al requisito de atomicidad, si una parte de la transacción es
abortada, en consecuencia, debe abortarse también la transacción en su totalidad.
Cuando un cliente solicita la consumación al coordinador, el protocolo se ejecuta en dos
fases.
-En una primera fase del protocolo, cada participante vota para que la transacción
sea consumada o abortada. Se dice que un participante está estado preparado si
finalmente será capaz de consumar la transacción. Para estar seguro de esto, cada
participante guarda en un dispositivo de almacenamiento permanente todos los
objetos que haya alterado durante la transacción.

-En la segunda fase del protocolo, todo participante en la transacción lleva a cabo la
decisión conjunta. Si alguno de los participantes vota por abortar, entonces la
decisión ha de ser abortar. Si todos los participantes votan consumar, entonces la
decisión es de consumar la transacción.

11
 La siguiente figura muestra un resumen de las operaciones utilizadas en el protocolo
de consumación en dos fases.

Modelo de fallos. Los protocolos de consumación se diseñan para sistemas asíncronos, en el

cual pueden caer los servidores o pueden producirse pérdidas de mensajes. Sin embargo, se
supone que no hay fallos bizantinos (aleatorios o maliciosos) porque un protocolo subyacente
elimina los mensajes duplicados y los corruptos.

El protocolo de consumación en dos fases es un ejemplo de un protocolo para alcanzar el

consenso en un sistema asíncrono en el cual los procesos pueden fallar. Esto se debe a que los
fallos por caídas de los procesos se enmascaran reemplazando el proceso caído por un nuevo
proceso cuyo estado se establece partiendo de la información guardada en un dispositivo de
almacenamiento permanente.

 4. Control de concurrencia distribuido.

Cada servidor gestiona un conjunto de objetos y es responsable de asegurar que éstos
mantienen su consistencia cuando se accede a ellos desde transacciones concurrentes. Por lo
tanto, cada servidor es responsable de aplicar un control de concurrencia sobre sus propios
objetos.

4.1 Bloqueos
En una transacción distribuida, los bloqueos sobre un objeto se mantienen localmente. El gestor
de bloqueos locales puede decidir la concesión de un bloqueo o hacer que la transacción espere.
Sin embargo, no puede liberar ningún bloqueo hasta que sepa que la transacción se ha
consumado o ha abortado en todos los servidores involucrados en dicha transacción. Una
transacción abortada libera sus bloqueos tras la primera fase del Protocolo de Consumación en
dos fases.

Dado que los gestores de bloqueos en distintos servidores fijan sus bloqueos con independencia
de los otros, es posible que distintos servidores impongan ordenamientos distintos sobre las
transacciones. Estas ordenaciones distintas pueden llevar a situaciones de interbloqueo
distribuido.

12
 4.2 Ordenación.
En las transacciones distribuidas, se requiere que el primer coordinador al que accede la
transacción proporcione al cliente una marca temporal para la transacción globalmente única.
La marca temporal de la transacción se pasa al coordinador de cada servidor sobre cuyos objetos
se realice una operación en la transacción.

Los servidores de transacciones distribuidas son responsables conjuntamente, de asegurar que

las transacciones se realicen de forma secuencialmente equivalente.

4.3 Control de concurrencia optimista.

Recuérdese que, con el control de concurrencia optimista, cada transacción se valida antes de
que se le permita consumarse. Una transacción distribuida es validada por un conjunto de
servidores independientes, cada uno de los cuales valida las transacciones que acceden a sus
propios objetos. Esto puede provocar que dos servidores validen en orden ligeramente distinto.

Antes se recomendaba una simplificación del protocolo de validación que establece una regla
por la que sólo una transacción puede realizar, cada vez, las fases de validación y actualización.
Sin embargo, en una transacción distribuida, se puede provocar un interbloqueo de
consumación.

En transacciones distribuidas se un usa un Protocolo de Validación Paralela (Kung & Robinson,

1981), el cual es una extensión de la validación hacia adelante o hacia atrás, para permitir que
varias transacciones estén al mismo tiempo en la fase de validación.

Cuando se utiliza una validación en paralelo, si los servidores realizan validaciones

independientes, es posible que distintos servidores de una transacción distribuida puedan
secuenciar el mismo conjunto de transacciones según ordenamientos diferentes. Para evitar que
esto suceda, se pueden utilizar dos algoritmos:
-Validación local + validación global (Ceri & Owiki, 1982). Consiste en que, tras cada
validación local en un servidor, tiene lugar una validación global que comprueba que la
combinación de las ordenaciones en los servidores sea secuenciable.

-Multi-Version Generalized Validation (Agrawal, 1987). Es una forma de validación en

paralelo que asegura que los números de transacción reflejan un orden secuencial.

13
  5. Interbloqueos distribuidos.
Los servidores deben o bien evitar que se produzcan interbloqueos, o bien detectarlos y
resolverlos. La utilización de timeouts para resolver posibles interbloqueos es una aproximación
tosca, ya que es difícil elegir un intervalo de timeout apropiado y las transacciones podrían ser
abortadas de forma innecesaria.

La mayoría de los esquemas de detección de interbloqueos funcionan detectando ciclos en los

grafos espera-a de las transacciones. Recuérdese que un grafo espera por es un grafo dirigido
en el cual los nodos representan transacciones u objetos, y los arcos representan un objeto o
una transacción esperando por un objeto. Existe un interbloqueo si y sólo si hay un ciclo en el
grafo espera por.

Interbloqueos fantasmas. Un interbloqueo que se detecta pero que realmente no lo es se

conoce como interbloqueo fantasma.

14