ALGORITMOS DE CONTROL DE CONCURRENCIA EN

BASES DE DATOS DISTRIBUIDAS

CARRANZA ATHÓ FREDY

BASES DE DATOS II
ESCUELA ACADÉMICO PROFESIONAL DE INFORMÁTICA
UNIVERSIDAD NACIONAL DE TRUJILLO
Trujillo Perú
2006

Resumen. El presente artículo tiene como finalidad presentar una descripción de dos algoritmos
muy reconocidos para el Control de Concurrencia en el ámbito de las bases de Datos
Distribuidas, como son el algoritmo de Dos Fases Distribuidos y el de Estampas de Tiempo.
Dichos algoritmos cuentan con particularidades diferentes siendo el primero el bloqueo y el
estado de los mismos en dos fases, y del segundo, la sincronización de las operaciones en base a
marcas de tiempo. Dichos algoritmos son usados comercialmente, y son los más conocidos en el
ámbito de las Bases de Datos, de manera que su conocimiento es base para un buen estudio.

1. INTRODUCCIÓN

Con el mayo avance de las redes y los procesos distribuidos, las Ciencias de la Computación y en
especial el área de las Bases de Datos, tienen como menester incluir en ellas, propósito de mejora y
cambio. Bien conocido por todos es, que las Bases de datos son un punto importante en cualquier
estructura que se base en redes, pero la resolución de este problema no es tarea fácil, considerando que
las operaciones en una red son constantes y los usuarios exigen rapidez y eficiencia.

Así pues, una de las mayores preocupaciones es resolver el caso de la concurrencia. Esta concurrencia,
mucha o poca, viene a ser un problema a resolver, es por eso que se presentan algoritmos que permiten
ayudar en estos campos.

El presente documento presentará dos de los más importantes algoritmo de Control de Concurrencia,
ellos son el conocido Algoritmo de Bloqueo de Dos Fases(2PL) y el de Estampas de Tiempo(TS). Estos
algoritmos diferentes en su estructura, pretenden resolver cualquier dificultad en la ejecución de las
múltiples ejecuciones de las operaciones en un entorno de Bases de Datos Distribuidas.

El 2PL básicamente nos enfocará en un ámbito de bloqueos y desbloqueos que para algunos resulta
tedioso, pero que ciertamente es el más usado comercialmente, y el TS nos permitirá evitar estos
bloqueos, pero con el coste de necesitar mayores comparaciones y espacio auxiliar.

Los algoritmos presentados, resolverás los problemas en el Control de Concurrencia, pero eso no
equivale a decir que son los únicos, sino que simplemente son los más comerciales y conocidos. Dichos
algoritmos no solo mejorarán nuestro entendimiento en el estudio de las Bases de Datos Distribuidas
sino que permitirán obtener un mejor concepto del cómo y porqué se debe controlar la concurrencia.

2. ALGORITMO DE DOS FASES DISTRIBUIDO

2.1. DESCRIPCIÓN GENERAL

1
Existe un Lock Manager en cada sitio. Cada uno es responsable de la gestión de bloqueos de los datos
que hay en ese nodo, además de ello implementa el protocolo de control de concurrencia ROWA (Read
One Write All), lo que significa que se puede utilizar cualquier copia de un dato para ser leído, pero para
escribir se deben ser bloqueadas todas las copias. [Según 1]

En los candados de dos fases distribuidos se presentan despachadores en cada nodo del sistema. Cada
despachador maneja las solicitudes de candados para los datos en ese nodo. Una transacción puede leer
cualquiera de las copias replicada del elemento x, obteniendo un candado de lectura en cualquiera de las
copias de x. La escritura sobre x requiere que se obtengan candados para todas las copias de x. La
comunicación entre los nodos que cooperan para ejecutar una transacción de acuerdo al protocolo de
candados distribuidos de dos fases se presenta en la Figura 2.1.1. Los mensajes de solicitud de candados
se envían a todos los administradores de candados que participan en el sistema. Las operaciones son
pasadas a los procesadores de datos por los administradores de candados. Los procesadores de datos
envía su mensaje de "fin de operación" al administrador de transacciones coordinador.[Según 2]

Figura 2.1.1. Comunicación de bloqueos en el 2PL distribuido

Se distribuye un gestor de bloqueo en cada nodo. Cada uno es responsable de la gestión de bloqueos de
los datos que contiene en ese nodo. El 2PL distribuido implementa una protocolo de control de replicas
Read-One-Write-All. Cualquier copia de un dato replicado puede ser usada para operaciones de lectura,
pero todas las copias deben ser bloqueadas para escritura antes que se puedan modificar. [Según 3]

En el 2PL distribuido, cada transacción puede consistir de varias subtransacciones corriendo en sitios
diferentes. Aquí se considera lo siguiente que una planificación es serializable si es equivalente en su
efecto sobre la base de datos a una planificación serial. Además de ello el Bloqueo de dos fases exige que
los bloqueos se dividan en dos fases: fase de bloqueo (crecimiento) y fase de desbloqueo (decrecimiento).
[Según 4]

2.2. CARACTERÍSTICAS

A continuación se presenta las características que describen la actuación del algoritmo. Vale aclarar que
dada la múltiple bibliografía, las siguientes aseveraciones podrían variar en cuanto a ciertas estructuras
usadas para realizar el algoritmo, pero ello no significa que los algoritmos sean diferentes, sino que se
presenta una perspectiva distinta siempre con el mismo modelo a seguir.

En el algoritmo de detección de bloqueos totalmente distribuido, todos los controladores comparten

equitativamente la responsabilidad de detectar los bloqueos. En este esquema, cada una de las
localidades construye un grafo de espera local que representa una parte del grafo total, dependiendo del
comportamiento dinámico del sistema. La idea es que, si existe un bloqueo, aparezca un ciclo en (por lo
menos) uno de los grafos parciales. A continuación se presenta un algoritmo de este tipo, en el cual
requiere de la construcción de grafos parciales en todas las localidades.

Cada una de las localidades mantiene su grafo de espera local. Estos grafos locales difieren de los antes
mencionados en que se agrega un nodo adicional, Tex al grafo. Existirá un arco Ti
Tex en el grafo si

2
Ti está esperando un dato de otra localidad que esté siendo ocupado por cualquier otra transacción. De
manera similar, existirá un arco Tex
Ti en el grafo si existe una transacción en otra localidad que esté
esperando un recurso que Ti esté esperando en ésta.

En el caso en que un grafo de espera local contiene un ciclo en el que no participa el nodo Tex , entonces
el sistema se encontrará en un estado de bloqueo. Sin embargo, la existencia de un ciclo que incluya a
Tex , implica la posibilidad de que se haya presentado un bloqueo. Para verificar si es así, es necesario
invocar un algoritmo distribuido de detección de bloqueos.

Suponemos que el grafo de espera de la localidad Li contiene un ciclo en el que participa el nodo Tex
.Este ciclo debe tener la forma:

Tex
Tk1
Tk2
…
Tm
Tex

lo que indica que la transacción Tk de Li está en espera para poder ocupar un dato de alguna otra
localidad, por ejemplo Lj . Al descubrir este ciclo, la localidad Li mandará un mensaje de detección de
bloqueos a la localidad Lj, el cual contendrá información referente al ciclo.

Tex T2 T4
T1 T2

T5 T3 Tex
T3

Localidad L1 Localidad L2

Figura 2.2.1. Grafo de espera local

Cuando una localidad Lj recibe un mensaje de ese tipo, actualiza su grafo de espera local con la
información que acaba de obtener. Una vez hecho eso, determina si en el grafo de espera nuevo existe un
ciclo en el que no participe Tex. En caso afirmativo, se habrá detectado un bloqueo y se invocará un
esquema de recuperación apropiado. Si se descubre un ciclo en el que participe Tex, Lj transmitirá un
mensaje de detección de paralizaciones a la localidad correspondiente, por ejemplo Lk. La localidad Lk,
a su vez, repetirá el procedimiento. Así, después de un número finito de repeticiones, bien se habrá
detectado un boqueo, o se suspenderá el algoritmo de detección.

Para ilustrar lo anterior, examinamos los grafos de espera locales de la Figura 2.2.1. Suponemos que la
localidad L1 descubre el ciclo:

Tex
T2
T3
Tex

Puesto que T3 está esperando un dato de la localidad L2, la localidad L1 transmitirá un mensaje de
detección de paralizaciones que describa este ciclo a la localidad L2. En el momento en que L2 reciba este
mensaje, actualizará su grafo de espera local para producir el grafo de espera de la Figura 2.2.2. Este
grafo contiene el ciclo:

T2
T3
T4
T2

3
que no incluye al nodo Tex. Por tanto, el sistema está en estado de bloqueo y es conveniente invocar un
esquema de recuperación apropiado.

Tex T2 T4

Localidad L2
T3

Figura 2.2.2. Grafo de espera local

Es conveniente apuntar que el resultado habría sido el mismo si la localidad L2 y hubiera descubierto
primero el ciclo en su grafo de espera local y hubiera enviado el mensaje de detección de bloqueos a la
localidad L1. En el peor de los casos, las dos localidades descubrirían el ciclo aproximadamente al
mismo tiempo, con lo que se mandaría dos mensajes de detección de bloqueos, uno de L1 a L2 y otro de
L2 a L1. Esto conduce a una transferencia innecesaria de mensajes y un cierto retraso mientras se
actualizan los dos grafos de espera locales y se buscan ciclos en ambos grafos.

Para reducir el tráfico de mensajes, se asigna a cada transacción Ti un identificador único, denotado por
ID(Ti). En el caso en el que la localidad Lk descubra que su grafo de espera local contiene un ciclo en que
participa el nodo Tex y que tiene la forma

Tex
Tk1
Tk2
…
Tkn
Tex
sólo enviará un mensaje de detección de bloqueos a otra localidad si:

ID(Tkn)< ID(Tk1)

De no ser así, Lk continuará con su ejecución normal y dejará la responsabilidad de iniciar el algoritmo
de detección de bloqueos a alguna otra localidad.

Consideremos de nuevo los grafos de espera de la Figura 2.2.1 que mantienen las localidades L1 y L2.
Suponemos que:

ID(T1)< ID(T2)<ID(T3)≤ID(T4)

Suponemos que en ambas localidades descubren estos ciclos locales aproximadamente al mismo tiempo.
El ciclo en L1 tiene forma:

Tex
T2
T3
Tex

Puesto que ID(T3)>ID(T2), la localidad L1 no enviará un mensaje de detección de bloqueos a la localidad

L2.

El ciclo en la localidad L2 tiene forma:

Tex
T3
T4
T2
Tex

4
 Puesto que ID(T2)<ID(T3), la localidad L2 si enviará un mensaje de detección de bloqueos a la localidad
L1. Esta, al recibir el mensaje, actualizará su grafo de espera local, lo examinará para determinar si
contiene ciclos y descubrirá que el sistema está en estado de bloqueo. [Según 3]1

Aquí se presenta la caracterización desde otra óptica pero que permitirá obtener los mismos resultados.

Supongamos que la transacción T1 tiene dos subtransacciones:

T1.1 corriendo en S1 y escribiendo un nuevo valor para la copia A1 de A.
T1.2 corriendo en S2 y escribiendo un nuevo valor para la copia A2 de A.

Ahora supongamos que la transacción T2 tiene dos subtransacciones:

T2.1 corriendo en S1 y escribiendo un nuevo valor para la copia A1 de A.
T2.2 corriendo en S2 y escribiendo un nuevo valor para la copia A2 de A

Figura 2.2.3. Planeamiento 1 para las transacciones 1 y 2

Como se observa en la Figura 2.2.3. los elementos que aparecen en una misma línea podrían ocurrir
simultáneamente, o en cierto orden. Primero según el sitio S1, T1.1 debe preceder a T2.1 (T1 antes que
T2). Y por el otro lado, según el sitio S2, T2.2 debe preceder a T1.2 (T2 antes que T1). Por lo tanto, esta
planificación no es serializable.

El problema de las transacciones distribuidas es que no sólo debemos controlar que se realicen
localmente los bloqueos en dos fases, sino en la transacción global. Por lo tanto, ninguna subtransacción
Ti.n de una transacción Ti puede liberar un bloqueo si otra subtransacción Tj.m (de Tj) realizará después
un bloqueo (read-lock o write-lock). Ejemplo,

En la planificación 1 la transacción T1 viola este principio pues T1.1 libera el bloqueo sobre A1 antes que
T1.2 bloquee a A2.

En el bloqueo de dos fases estricto cada subtransacción debe informar a las otras subtransacciones de que ha
requerido todos los bloqueos. Luego de que todas las transacciones completaron su fase 1 (de bloqueo)
pueden continuar con las lecturas y escrituras para luego liberar los bloqueos (unlock). [Según 4]

3. ALGORITMO DE ESTAMPAS DE TIEMPO DISTRIBUIDO

3.1. DESCRIPCIÓN GENERAL

En un sistema distribuido, cada transacción debe tener una estampilla de tiempo única para usar en la
decisión del orden de serializabilidad. Para la generación de estampillas únicas, en el modelo

1 La referencia a la bibliografía comprende desde el inicio del apartado 2.2. hasta la misma nota de referencia

5
distribuido: cada transacción tiene una estampilla de tiempo que surge de concatenar la estampilla de
tiempo local con el identificador de sitio.

El problema del modelo distribuido es que un sitio podría generar estampillas de tiempo a mayor
velocidad que otros sitios. En ese caso, las estampillas de tiempo generadas por el sitio más rápido serán
mayores que las generadas por otros sitios. Esto se evita si cada sitio utiliza un reloj lógico,
implementado mediante un contador que se incrementa cada vez que se genera una nueva estampilla de
tiempo local. Para sincronizar los relojes lógicos, se requiere que cada sitio Si avance su reloj lógico
cuando arriba una nueva transacción a ese sitio. [Según 4]

A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no
pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de
serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el
administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts( Ti )
cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada
transacción 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 igualemente
crecientes. Así, las estampas de tiempo son valores derivados de un dominio totalmente ordenado.
[Según 2]

Timestamp es un mecanismo en que el orden del serialización se selecciona a priori; la ejecución de la

transacción es obligada a obedecer este orden. En el timestamp, cada transacción está tiene asignado un
único timestamp por el sincronizador. Obviamente, para lograr un único timestamp para las
transacciones que llegan de nodos diferentes de un sistema distribuido, todos los relojes en todos los
nodos deben sincronizarse y además deben resolverse dos timestamps idénticos.
Lamport [Según 6] ha descrito un algoritmo para sincronizar los relojes distribuidos vía el paso de un
mensaje. Si un mensaje llega a un nodo local de un nodo remoto con un timestamp más alto, se supone
que el reloj local es más lento que el anterior.

El reloj local es incrementado por el timestamp del recientemente mensaje recibido. De esta manera
todos los relojes están avanzados hasta que ellos sean sincronizados. En el otro esquema dónde dos
timestamps idénticos no deben asignarse a dos transacciones, cada nodo asigna un timestamp a sólo
una transacción a cada tictac del reloj. Además el tiempo del reloj local se guarda en los bits de MSI y
los identificadores del nodo son guardados en los bits LSI. Dado que los identificadores de los nodos
son diferentes, este procedimiento asegurará un único timestamp.

Cuando los operaciones de dos transacciones entran en conflicto, se exige ser procesadas en el orden del
timestamp. Es fácil demostrar que el orden timestamp (TSO) produce historias serializables. Thomas ha
estudiado la exactitud y aplicación de este acercamiento y lo describió. Esencialmente cada nodo
procesa los funcionamientos contradictorios que el timestamp pida, cada relación de conflicto leer-
escribe y escribir-escribir está resuelta por el orden del timestamp. Por consiguiente todos los caminos
en la relación están en el orden del timestamp y, desde que todas las transacciones tienen un único
timestamp, se asume que ningún ciclo es posible en un gráfico que representa la transacción las
historias. [Según 5]

6
3.2. CARACTERÍSTICAS

Existen varias formas en que las estampas de tiempo se pueden asignar. Un método 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 autónoma
las estampas de tiempos basándose 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 posición 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 también una estampa de tiempo a todas las operaciones
solicitadas por una transacción. Más aún, 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
más 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 transacción más vieja y Tk se dice ser una transacción más joven.

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

for Ri(x) do begin for Wi(x) do begin

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

La acción de rechazar una operación, significa que la transacción que la envió necesita reiniciarse para
obtener la estampa de tiempo más reciente del dato e intentar hacer nuevamente la operación sobre el
dato.

Ordenamiento conservador por estampas de tiempo

El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan pronto como se
recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos
reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operación
hasta que exista la seguridad de que no será reiniciada. La forma de asegurar lo anterior es sabiendo que
ninguna otra operación 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 creación de interbloqueos
(deadlocks).

Ordenamiento por estampas de tiempo múltiples

7
Para prevenir la formación de interbloqueos se puede seguir la estrategia siguiente. Al hacer una
operación de escritura, no se modifican los valores actuales sino se crean nuevos valores. Así, puede
haber copias múltiples de un dato. Para crear copias únicas se siguen las siguientes estrategias de
acuerdo al tipo de operación de que se trate:

Una operación de lectura Ri(x) se traduce a una operación de lectura de x de una sola versión
encontrando la versión de x, digamos xv, tal que, ts(xv) es la estampa de tiempo más grande que tiene
un valor menor a ts(Ti).

Una operación 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)
[Según 2]

Otra forma de presentar este algoritmo es de la siguiente manera:

En este algoritmo se guardan el momento (tiempo) en que se realizo alguna operación sobre la base de
datos. Estas estampas de tiempo son utilizadas en el vector de recepción.

El coordinador del sitio C (lugar donde se genera la transacción) ejecuta todas sus lecturas y escrituras
localmente, posteriormente se transmiten las operaciones a los otros sitios participantes en la operación,
junto con el vector de recepción con la entrada del sitio C actualizada con la estampa de tiempo de la
transacción, la ejecución del algoritmo se describe a continuación:

Cada sitio participante P compara su vector de recepción con la entrada del coordinador en el sitio P,
tendiendo los casos:

Sí la entrada del vector de recepción que acaba de recibir es igual al de su propio vector, el participante
puede realizar la escritura, ya que el sitio P ha ejecutado todas las acciones sobre el objeto o originadas
en C, y se le asigna la estampa de tiempo de P al vector de recepción en la entrada del sitio C.

Sí la comparación falla, es decir, la estampa de tiempo del participante no es igual a la del coordinador,
se cancelará la transacción en P, y no se aceptará ninguna escritura posterior para esa transacción en
particular.

Al término de la transacción el coordinador fuerza la escritura de un registro de terminación exitosa

(commit) en el archivo log[8], causando la atomicidad, y una confirmación independiente en el sitio
coordinador. El sitio coordinador envía esta decisión a los demás sitios participantes, cada participante
que aceptaron todas las escrituras, confirma hasta que se recibe la decisión del coordinador, registrando
en el archivo log el registro commit, después envía un mensaje al coordinador indicando que la
confirmación fue satisfactoriamente ejecutada. Dado que la decisión de confirmación de cada
subtransacción es hecha localmente, el algoritmo es no-bloqueable.

En el caso de los que no pudieron participar o cancelaron el coordinador no recibe un acuse de esta
decisión. Por lo que en cada sitio se guarda un registro de reconciliación en donde se almacenan los
datos (objeto, sitio) en una tabla llamada Registro, el coordinador nota que un participante P no ha
aceptado su decisión, por lo que inserta un registro en la tabla de reconciliación.

La reconciliación entre dos sitios (S y P) sobre el objeto o se efectúa de la siguiente manera:

Si el sitio S tiene una tupla (o, p) en su tabla Registro, S inicia la reconciliación enviando una solicitud de
reconciliación al sitio P junto con el vector de recepción. Si el nodo P acepta la reconciliación, P envía a S
su vector de recepción para el objeto “o” de la tupla.

8
 Cada sitio utiliza el vector de recepción que ha recibido y busca en su propio archivo log aquellas
acciones que no se han ejecutado en el otro sitio, tales acciones son seleccionadas comparando la
estampa de tiempo de cada una de las opciones con la entrada de su sitio coordinador en el vector de
recepción.

Estas acciones son extraídas y enviadas al otro sitio. Cuando el sitio recibe estas acciones, las ejecuta y las
agrega a su archivo log. Al final de la reconciliación, se actualiza el vector de recepción de ambos sitios,
la actualización del vector es: a cada entrada se le asigna el valor máximo de las entradas
correspondientes de los dos vectores.

Después de la actualización del vector de recepción, un sitio conforma la reconciliación localmente y

fuerza un registro de confirmación en su archivo log.

Después de ello, no hay necesidad de que haya comunicación entre los sitios. Efectivamente, el sitio S o P
podrían cancelar mientras los demás confirman.

4. CONCLUSIONES

- Como se notó para el algoritmo de Bloqueo de Dos Fases Distribuido, su característica primordial es
el bloqueo y la división de los bloqueos en dos fases primordiales como son las del crecimiento y
decrecimiento. Estas fases permitirán asegurar del todo que las operaciones no caigan en conflicto,
pero con la desventaja de que las copias de los datos en cualquiera de los nodos participantes estará
totalmente inservible hasta el momento de que la transacción correspondiente haga commit. Vale
decir que los bloqueos impedirán de cierta manera el acceso a los datos, con la finalidad de evitar la
inconsistencia.

- El algoritmo de Estampas de Tiempo Distribuido, logra evitar los bloqueos a los datos y cualquier
tipo de inconveniencia con un acceso libre a la información. Este algoritmo propone una
sincronización con tiempos que facilita enormemente el control de la concurrencia en todo el
sistema. Ya que las operaciones deben seguir un orden establecido por la marca de tiempo que los
acompaña. Si bien es cierto el algoritmo se ve aparentemente más eficiente, pero por otro lado usa
muchas estructuras para almacenar la información del estado de las transacciones y las operaciones.

- El Control de Concurrencia siempre ha sido y será un tema de estudio y profundo análisis en el

mundo de las Ciencias de la Computación, dicho así se diría que los algoritmos presentados, si bien
resuelven los altercados que se presentasen en una ejecución de operaciones distribuidas, no son los
únicos que lo podrán hacer; y esto va mucho más allá, ya que como el estudio es continuo y
profundo, muy cierto será de que nuevos algoritmos más eficientes reemplacen a éstos.

REFERENCIAS BIBLIOGRÁFICAS

[1] H. D. RAMÓN, Conceptos de Bases de datos distribuidas[en línea], Argentina, 2006, disponible en:
<https://lidi.info.unlp.edu.ar/~fernando/clases.ppt>
[2] A. DÍAZ PEREZ, Sistema de bases de datos distribuidos[en línea], México, 2002, disponible en:
< http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_6.html>
[3] C. JIMENEZ QUINATANA, Bases de datos distribuidas[en línea], Universidad de Concepción, Chile,
2002, disponible en:
< http://www.inf.udec.cl/~basedato/>
[4] M. MERCEDES VITTURINI, Elementos de Bases de Datos, Informe inédito, Universidad Nacional del Sur –
Argentina , 48 pág, 2005

9
 [5] B. BHARGAVA, Concurrency Control in Database Systems, Informe inédito, IEEE, 1999
[6] L. LAMPORT, Time Clocks and the Ordering of Events in a Distributed System, ACM, vol 21, 1989

Título del trabajo: ALGORITMOS DE CONTROL DE CONCURRENCIA EN BASES DE DATOS

DISTRIBUIDAS
Alumno: CARRANZA ATHÓ FREDY

Referencias
Veracidad Actualidad Claridad Profundidad Autenticidad Formato
Bibliográficas

10