Bases de Datos Distribuidas

ADMINISTRACIN DE
TRANSACCIONES DISTRIBUIDAS
Objetivo: El alumno explicar la importancia de
controlar y administrar transacciones
distribuidas
ADMINISTRADOR DE TRANSACCIONES
El modulo Administrador de transacciones
distribuidas se encarga de asegurar la atomicidad
de las transacciones globales y de cada
componente de la subtransaccin.
El administrador de transacciones coordina las
transacciones generadas por los programas de
aplicacin, a travs de una comunicacin con el
scheduler.
El Scheduler es el modulo responsable de
implementar una estrategia particular para el
control de concurrencia.
Recopil: Dra. Mara del Pilar Angeles
SCHEDULER
El scheduler es una secuencia de las operaciones
para un conjunto de transacciones concurrentes
que preserva el orden de las operaciones en cada
una de las transacciones individuales.
El
objetivo
del
scheduler
(horario
o
calendarizador) es maximizar la concurrencia sin
permitir
la
ejecucin
concurrente
de
transacciones que interfieran unas con otras y
que por tanto comprometan la consistencia de la
base de datos.
Atomicidad
Ambiente
Centralizado: Las sentencias

que se ejecutan en una transaccin deben
ejecutarse como un todo.
Ambiente
Distribuido:
Las
subtransacciones que se ejecutan en una
transaccin global deben ejecutarse como
un todo.
Control de Concurrencia
El
control de concurrencia administra la

ejecucin de operaciones simultneas sin
permitir que estas operaciones interfieran
unas con otras.
El
control de concurrencia se encarga de

maximizar la concurrencia y garantizar la
consistencia
y atomicidad
de
las
transacciones, debe evitar o manejar
errores
de
concurrencia
como
el
interbloqueo (deadlock).
El control de concurrencia y la recuperacin en
un entorno distribuido, debe presentar soluciones
a problemas que no surgen en ambientes
centralizados. Por ejemplo:
Manejar mltiples copias de los elementos de
datos:
Fallos de sitios individuales:
Fallo de enlaces de comunicacin:
Confirmacin distribuida:
Bloqueo mortal (deadlock) distribuido:
Manejar mltiples copias de los elementos de

datos: El mtodo de control de concurrencia tiene
a obligacin de mantener la consistencia entre
estas copias.
El mtodo de recuperacin debe cuidar que una

copia sea consistente con las dems si el sitio en
el que la copia estaba almacenada falla y se
recupera posteriormente.
Fallos de sitios individuales: EL Manejador

de BDD debe continuar operando con sus sitios
activos, si es posible, cuando fallen uno o mas
sitios individuales. Cuando un sitio se recupere,
su bd local se deber poner al da con los dems
sitios antes de que se incorpore al sistema.
Fallo de enlaces de comunicacin: El sistema

debe ser capaz de manejar el fallo de uno o mas
de los enlaces de comunicaciones que conectan los
sitios. Un caso extremo de este problema es que
puede haber particin de la red. Esto divide los
sitos en dos o mas particiones, dentro de las
cuales los sitios pueden comunicarse entre si,
pero no con sitios de otras particiones.
Confirmacin distribuida: Puede haber

problemas para confirmar una transaccin que
esta teniendo acceso a base de datos almacenadas
en mltiples sitios si algunos de estos fallan
durante el proceso de confirmacin. A menudo se
utiliza el protocolo de confirmacin en dos fases
(tema ya visto) para resolver este problema.
Deadlock distribuido: Puede ocurrir un

bloqueo mortal entre varios sitios, lo que hace
necesario extender las tcnicas de manejo de
deadlocks.
CONTROL DE CONCURRENCIA DISTRIBUIDO

BASADO EN UNA COPIA DISTINGUIDA.
La idea es designar una copia determinada de

cada elemento de base de datos como copia
distinguida.
Los bloqueos para este elemento se asocian a la
copia distinguida y todas las solicitudes de
bloqueo o desbloqueo se envan al sitio que
contiene esa copia.
TCNICA DE SITIO PRIMARIO:
En este mtodo se designa un solo sitio primario

como sitio coordinador para todos los elementos
de la base de datos.
Por tanto todos los bloqueos se mantienen en ese

sitio, y todas las solicitudes de bloqueo y
desbloqueo se envan a ese sitio. As pues este
mtodo
es
una
extensin
del
bloqueo
centralizado.
TCNICA DE SITIO PRIMARIO:
Por ej. Si todas las transacciones siguen e

protocolo de candado de dos fases (2PL), la
seriabilidad esta garantizada.
La ventaja de este enfoque es que es una simple
extensin del esquema de candados centralizado
y no es complejo.
Sin embargo como todas las solicitudes de

candado se van a un sitio este sitio se sobrecarga.
Si este sitio falla, se paraliza todo el sistema.
SITIO PRIMARIO CON SITIO DE RESPALDO
Este enfoque busca subsanar la segunda

desventaja del mtodo anterior designando un
segundo sitio como sitio de respaldo.
Toda la informacin de bloqueo se mantiene al
tanto en el sitio primario como en el de respaldo.
En caso de fallar el sitio primario el de respaldo
asume sus funciones y el procesamiento puede
reanudarse una vez que se elija el nuevo sitio de
respaldo y la informacin de estado de los
candados se copie en l.
SITIO PRIMARIO CON SITIO DE RESPALDO
Sin embargo, el proceso de adquisicin de

candados se hace mas lento, porque todas las
solicitudes de candados se deben guardar tanto
en el sitio primario como en el de respaldo antes
de enviar una respuesta a la transaccin
solicitante.
TCNICA DE COPIA PRIMARIA
Este mtodo intenta distribuir la carga de la

coordinacin de los candados entre varios sitios
manteniendo las copias distinguidas
de
diferentes elementos de datos almacenados en
diferentes sitios.
El fallo de un sitio afecta a todas las
transacciones que estn teniendo acceso a
candados sobre los elementos de BD cuyas copias
primarias residan en ese sitio, pero las dems
transacciones no resultan afectadas. Este mtodo
tambin puede usar sitios de respaldo para elevar
la fiabilidad y disponibilidad.
ELECCIN DE UN NUEVO SITIO

COORDINADOR EN CASO DE FALLO
Siempre que un sitio coordinador falle en
cualquiera de las tcnicas anteriores, los sitios
siguen activos debern elegir un nuevo
coordinador.
En el caso del enfoque del sitio primario sin sitio
de respaldo, ser preciso abortar y reiniciar todas
las transacciones en ejecucin, y el proceso de
recuperacin ser bastante tedioso. Parte de
dicho proceso implica elegir un nuevo sitio
primario y crear un proceso administrador de
candados y un registro de toda la informacin de
los candados en ese sitio.

En los mtodos que usan sitios de respaldo, el

procesamiento de transacciones se suspende
mientras el sitio de respaldo se designa como
nuevo sitio primario, se escoge un nuevo sitio de
respaldo y se envan a el copias de toda la
informacin de los candados del nuevo sitio
primario.

Si el sitio de respaldo X esta a punto de

convertirse en el nuevo sitio primario, X puede
escoger el nuevo sitio de respaldo entre los sitios
activos del sistema.
Sin embargo, si no hay sitio de respaldo, o si

estn cados tanto el sitio primario como el de
respaldo, se puede seguir el proceso denominado
eleccin para escoger el nuevo sitio coordinador.

En este proceso, cualquier sitio Y que intente
comunicarse
repetidamente
con
el
sitio
coordinador y fracase puede suponer que el
coordinador esta cado e iniciar el proceso de
eleccin enviando un mensaje a todos los sitios
activos en el cual proponga que Y se convierta en
el nuevo coordinador.
Tan pronto como Y reciba una mayora de votos
afirmativos, puede declararse nuevo coordinador.

BASADO EN VOTACIN
En el mtodo de votacin, no hay copia

distinguida, sino cada solicitud de candado se
enva a todos los sitios que incluyan una copia del
elemento de datos.
Cada copia mantiene su propio candado y puede

conceder o rechazar la solicitud.

BASADO EN VOTACIN
Si la mayora de las copias otorgan un candado a

la transaccin que lo solicita, esta poseer el
candado e informar a todas las copias que le ha
sido concedido.
Si una transaccin no recibe la mayora de los

votos de concesin del candado durante un cierto
periodo de tiempo predefinido, cancelar su
solicitud e informar de ello a todos los sitios.

BASADO EN VOTACIN
El mtodo de votacin se considera un mtodo de

control
de
concurrencia
verdaderamente
distribuido, ya que la responsabilidad de la
decisin recae en todos los sitios implicados.
Sin embargo requiere un trafico mas alto de
mensajes entre sitios.
Deadlocks
Interbloqueo distribuido: se presenta cuando
se desarrolla una espera circular entre dos
transacciones y cada una de estas solicita una
actualizacin sobre la misma tabla, no permite a
otros usuarios el recurso hasta que termine el
proceso.
Comnmente se maneja este problema de
concurrencia
escogiendo
una
vctima
y
cancelndola para que el otro proceso termine
satisfactoriamente. La vctima ser aquel proceso
con menor tiempo de CPU ejecutado al momento
del conflicto.
GRAFICA DE ESPERA LOCAL (LWFG)
La grfica de espera (LWFG) describe el estado

de asignacin de recursos.
Cuando un proceso Pi en el sitio A necesita de un

recurso retenido por Pj en el sitio B, Pi enva un
mensaje de solicitud al sitio B.
Se inserta una arista Pi Pj en la grfica de
espera local del sitio B
GRAFICA DE ESPERA LOCAL (LWFG)
Si cualquier grfica de espera local tiene un ciclo,

entonces ha ocurrido un bloqueo mutuo
(deadlock).
El hecho de que no haya ciclos en cualquiera de
las grficas de espera locales no significa que no
haya deadlocks.
Para detectar un deadlock, debemos demostrar

que la unin de las LWFG no tiene ciclos, lo cual
corresponde a la grafica de espera global GWFG.
EJEMPLO DE DEADLOCK DISTRIBUIDO
T: Transaccin, S: Sitio
T1 iniciado en S1 y requiere un candado en el

sitio S2
sitio S3
sitio S1
Las transacciones asignan candados compartidos

(lectura) y candado exclusivos (escritura) como se
ilustra a continuacin donde el read_lock(ti,xj)
denota un candado compartido por la transaccin
ti en el objeto xj y el write_lock(ti,xj) denota un
candado exclusivo por la transaccin Ti en objeto
xj.
Tiempo
S1
S2
t1
read_lock(T1x1)
t2
write_lock(T1,y1) write_lock(T2,z2)
t3
write_lock(T3,x1) write_lock(T1,y2)
write_lock(T2,y2)
S3
read_lock(T3,z3)
write_lock(T2,z3)
Realizando las LWFG, se tiene:
T3
T1
T2
T1
T2
T3
Individualmente no hay ciclos T3T1, T1T2,

T2T3, sin embargo al juntarlos para general la
GWFG , entonces si existe el ciclo
T1T2T3T1
T1
T2
T3
MTODOS PARA DETECCIN Y MANEJO DE

DEADLOCKS
Existen tres mtodos comunes para la deteccin y

manejo de interbloqueos.
Deteccin de interbloqueos centralizado

Deteccin de interbloqueos jerrquico
Deteccin de interbloqueos distribuido
DETECCIN DE DEADLOCKS
CENTRALIZADO
Un sitio es asignado como coordinador de

deteccin de deadlocks (DDC).
El DDC tiene la responsabilidad de construir y

mantener la grafica de espera global GWFG.
Peridicamente cada manejador de deadlocks
transmite su WFG al coordinador.
DETECCIN DE DEADLOCKS
CENTRALIZADO
El DDC construye el GWFG y busca ciclos en ella

El DDS selecciona una victima para romper el
ciclo (por un rollback transaction)
El DDC debe informar a los sitios acerca del

rollback.
Desventaja: Overhead en el sitio central
DETECCIN Y MANEJO DE DEADLOCKS

DISTRIBUIDOS JERRQUICOS
Los sitios se organizan jerrquicamente
En el nivel 1 (hojas) se encuentran todos los sitios

En el nivel 2 (medios) estn los sitios de deteccin de
deadlocks DD.
En el nivel 3 (raz) esta el sitio de deteccin de
deadlock global DDD.
DDD
DD43
DD12
S1
S2
S3
DD567
S4
S5
S6
S7

DISTRIBUIDOS JERRQUICOS
Cada sitio manda su LWFG al sitio de deteccin
correspondiente.
El DD esta fsicamente almacenado en algn sitio
participante.
Se asigna un nivel coordinador que es el que
actualiza el LWFG y se lo manda al DDD.
El DDD es el que detecta y maneja los deadlocks.
Ventaja: Se reduce dependencia en un sitio de

deteccin centralizado.

DISTRIBUIDO
Todos los sitios mantienen la grafica de espera de

todos los sitios participantes.
Los sitios transmiten su LWFG a los dems.

El sitio que detecte el deadlock selecciona
victima, cancela y anuncia a los dems.
Desventaja: Mucho overhead y tiempo en todos los

sitios.
MECANISMOS DE MARCAS DE
TIEMPO (TIMESTAMP)
Las marcas de tiempo (MT) son identificadores nicos que

se asignan a las transacciones y que pueden considerarse
como el tiempo de inicio de la transaccin.
Esta tcnica permite ordenar las transacciones y controlar

un acceso en secuencia de las mismas a los datos.
Con esta tcnica no existen interbloqueos, y todas las
actualizaciones fsicas se retrasan hasta la grabacin de las
transacciones, si una transaccin quiere acceder a algn
dato que ha sido actualizado por una ms reciente, se
deshace y se vuelve a empezar.
MARCAS DE TIEMPO
Las marcas de tiempo se usan cuando no se imponen
candados pero se sigue asegurando secuencialidad.
A cada transaccin i (Ti) se le asocia una marca de tiempo

MT(Ti ).
Si se asigna una MT a Ti y una nueva transaccin j (Tj) se
inicia en el sistema, entonces MT(Ti) < MT(Tj).
El valor de MT(Ti) puede extraerse del reloj del sistema o

con contadores lgicos de transacciones.
MARCAS DE TIEMPO
A cada elemento de datos D se le asocian dos

marcas temporales:
MTR(D): mayor marca temporal de todas las
transacciones que ejecutan con xito READ D;
MTW(D ): mayor marca temporal de todas las

transacciones que ejecutan con xito WRITE D;
Mecanismos de marcas de tiempo

(timestamp)
Existen varios protocolos basados en marcas de

tiempo, entre los que destacan: WAIT-DIE que
obliga a una transaccin a esperar en caso de que
entre en conflicto con otra transaccin cuya
marca de tiempo sea ms reciente, o a morir
(abortar y reiniciar).
Si la transaccin que se est ejecutando es ms

antigua WOUND-WAIT, se le permite a una
transaccin matar a otra que posea una marca de
tiempo ms reciente, o bien la transaccin
peticionaria se ve forzada a esperar.
MARCAS DE TIEMPO MULTI VERSIN
El mecanismo de marcas de tiempo supone que

existe una nica versin de los datos; por lo que
slo una transaccin puede acceder a los mismos.
Se puede relajar esta restriccin permitiendo que
varias transacciones lean y escriban diferentes
versiones del mismo dato siempre que cada
transaccin vea un conjunto consistente de
versiones de todos los datos a los que accede.
PROTOCOLO DE ORDENACIN POR MARCAS

DE TIEMPO
1.
Asegura que todas las operaciones leer y escribir

conflictivas se ejecutan en el orden de las marcas de
tiempo.
Supngase que la transaccin Ti ejecuta READ(D).
a. Si MT(Ti)<MTW(D) entonces Ti necesita leer un valor
de D que ya se ha sobrescrito. Por tanto se rechaza la
operacin READ y la transaccin Ti se aborta (rollback).
13:45 < 14:40 Ti pide leer D a las 13:45 y lo que obtengo

es algo que ya se actualiz a las 14:40, se aborta Ti para
que se inicie despus y MT(Ti)>MTW(D)

DE TIEMPO
1.
Supngase que la transaccin Ti ejecuta READ(D).

b. Si MT(Ti) MTW(D) entonces se ejecuta la
operacin READ y MTR(D) se asigna el valor mximo
entre MTR(D) y MT(Ti).
15:05>= 14:40 Ti pide leer D a las 15:05 y la ltima

escritura ocurri a las 14:40, entonces puede leer y
actualiza el ltimo tiempo de lectura de D.
MTR(D)= 15:05
(Recuerde que si Ti se selecciona antes que Tj , entonces
(MT(Ti)<MT(Tj)

DE TIEMPO
2. Supngase que la transaccin Ti ejecuta WRITE(D).
a. Si MT(Ti) < MTR(D) esto significa que el valor de D,
al cual Ti se encuentra modificando, ha sido
previamente ledo por otra transaccin, entonces se
rechaza la operacin WRITE y Ti se cancela.
b. Si MT(Ti) < MTW(D) entonces Ti est intentando
escribir un valor de D obsoleto. Por tanto, la operacin
WRITE se ignora.
c. En cualquier otro caso se ejecuta la operacin WRITE
y a MTW(D) se le asigna el valor mximo entre
MTW(Ti) y MT(Ti)
TCNICAS OPTIMISTAS
Otra modalidad para el control de accesos

concurrentes, la constituyen las denominadas
tcnicas optimistas.
Permiten que las transacciones accedan
libremente a los objetos, determinando antes de
su finalizacin si ha habido o no interferencias.
TCNICAS OPTIMISTAS
Cada transaccin consta de dos o ms fases: una

fase de lectura, una fase de validacin, y
posiblemente una fase de escritura.
Durante la fase de lectura todas las escrituras
tienen lugar en copias locales (versiones
transitorias) y durante la fase de validacin se
establece si se viola la secuencialidad, y las
copias locales se hacen globales.
MODELOS DE TRANSACCIONES:
Transaccin plana
Transaccin plana con savepoints
Transaccin anidada cerrada
Transacciones anidadas abiertas
Un modelo de transaccin multi-nivel
TRANSACCIN PLANA (TP)

Transaccin plana: Una transaccin plana es
un bloque bsico de operaciones en una
aplicacin.
Las operaciones no se pueden dividir, es decir, no
existen partes lgicas de la transaccin que
puedan ser tratadas en forma individual, de tal
forma que sea posible la validacin o cancelacin
slo de ciertas partes de la transaccin. Esto
debido a la propiedad de atomicidad.
TRANSACCIONES PLANAS CON PUNTOS DE

SALVADO
La atomicidad es una caracterstica importante

para los sistemas centralizados pero no es til
para las arquitecturas distribuidas.
Por lo tanto, es una desventaja de las TP que no
sea posible realizar validaciones o cancelaciones
de pequeas partes de la transaccin; o validar
resultados en varios pasos.
TP CON SAVEPOINTS
Un savepoint es un marcador definido por el

usuario dentro de la transaccin que permite que
porciones de la transaccin se puedan deshacer.
Un rollback puntoA, realiza un rollback en la
transaccin hasta ese puntoA. Todas las
sentencias o procedimientos entre ese punto de
salvado y el rollback se deshacen.
TRANSACCIONES PLANAS CON PUNTOS DE

SALVADO
El mecanismo savepoints permite ir guardando

estados de la transaccin que son validos, para que en
caso de fallas no tenga que abortar toda la
transaccin, sino hasta ciertos puntos (savepoints).
Se establece un savepoint cuando se invoca una

sentencia que hace que el sistema registre el estado
actual del proceso de la transaccin.
Nota: En Sybase ASE save transaction <nombredel savepoint>
TRANSACCIN PLANA CON SAVEPOINTS
Esta
sentencia
establece
el
identificador
que
posteriormente puede ser utilizado para restablecer el
estado hasta dicho identificador mediante otra sentencia
para indicar que toda la transaccin sea abortada, slo se
indica el punto hasta donde deshacer los efectos
realizados.
Nota: En Sybase ASE rollback transaction <nombredel savepoint2>
EJEMPLO
begin transaction royalty_change

update titleauthor set royaltyper = 65 from titleauthor, titles
where royaltyper = 75 and titleauthor.title_id = titles.title_id
and title = "The Gourmet Microwave"
update titleauthor
set royaltyper = 35 from titleauthor, titles
where royaltyper = 25 and titleauthor.title_id = titles.title_id

and title = "The Gourmet Microwave"
save transaction percentchanged
update titles set price = price * 1.1
where title = "The Gourmet Microwave"
select (price * total_sales) * royaltyper

from titles, titleauthor where title = "The Gourmet Microwave"
and titles.title_id = titleauthor.title_id

rollback transaction percentchanged
commit transaction
En Oracle existen como SAVEPOINT desde 9i
TP CON SAVEPOINTS
Despus de actualizar registros de la tabla

titleauthor, se asigna un punto de salvado con el
nombre percentchanged.
Posteriormente se determina como el incremento
en un 10% en el precio de los libros, afecta las
ganancias y por tanto se eliminan los cambios
realizados por la transaccin hasta el punto de
salvado.
Nota: si existe un rollback sin punto de transaccin deshace
TODA la transaccin
MODELOS DE TRANSACCIONES:
Transaccin anidada cerrada: Atomicidad
forzada a nivel ms alto.
Transacciones anidadas abiertas: Permite
que resultados parciales de subtransacciones
puedan ser vistos fuera de la transaccin.
Un modelo de transaccin multi-nivel es
aquel donde el rbol de subtransacciones es
balanceado, es decir una operacin de larga
duracin
se
abstrae
en
suboperaciones
implementadas por un conjunto de operaciones
de bajo nivel).
TRANSACCIN ANIDADA O T. A. CERRADA

Una transaccin anidada T consiste en un conjunto
T = {t , t , . . ., t } de subtransacciones y en un
orden parcial P sobre T.
1
Cada t de T puede abortar sin obligar a que T

aborte. Puede que T reinicie t o simplemente no
ejecute t .
i
Si se compromete t , esa accin no hace que t sea

permanente, sino que t se compromete con T, y
puede que aborte si T aborta.
i
TRANSACCIN ANIDADA O T.A. CERRADA

La ejecucin de T no debe violar el orden parcial P.
Es decir, si aparece un arco t t en la grafica de
precedencia, t t no debe estar en el cierre
transitivo de P.
i
EJEMPLO DE TRANSACCIN ANIDADA

USE MyDB
GO
CREATE PROCEDURE Formular_pedido
AS
BEGIN TRAN Tran_pedidos

EXEC Formular_pedido
COMMIT TRAN Tran_pedidos
GO
BEGIN TRAN Tran_formular_pedido
-- Instrucciones SQL para la

formulacin del pedido
..
.
.
COMMIT TRAN Tran_formular_pedido
GO
TAREA: Investigar para

que sirven los SAVEPOINTS
en Sybase ASE y traer
ejemplos.
NOTA: Oracle no admite
transacciones anidades,
el usa el concepto de
transaccin autnoma.
DIFERENCIAS TRANSACCIN ANIDADA Y

AUTNOMA
Una transaccin autnoma se puede activar

desde otra transaccin, sin embargo no es
autnoma por las siguientes razones:
No comparte recursos transaccionales (como

candados) con la transaccion principal.
No depende de la transaccin principal. Si la
principal aborta, la transaccin anidada aborta
tambin, pero la autnoma no aborta.
Los cambios comprometidos son visibles a otras
transacciones de manera inmediata.
Una transaccin anidada con cambios no es visible a
otras transacciones hasta que la principal se
comprometa.
TRANSACCIN ANIDADA ABIERTA

En este modelo al igual que las transacciones
anidadas, una transaccin puede tener varias
sub-transacciones, las cuales a su vez, pueden
tener varias sub-transacciones formando as un
rbol de transacciones.
Las transacciones anidadas abiertas (Open Nested
Transaction) estn conformadas por una
jerarqua de transacciones sobre diferentes
niveles de abstraccin, y de un conjunto de
relaciones de conmutatividad que definen a cada
nivel
los
conflictos
entre
operaciones
predefinidas.
TRANSACCIN ANIDADA ABIERTA

Su principal diferencia con las TA radica en que las
sub-transacciones pueden validar a otras
subtransacciones (esto significa que sus efectos
son
visibles
a
otras
transacciones),
independientemente de la validacin de la
transaccin raz.
Otra diferencia con las transacciones anidadas
(cerradas), es que las transacciones anidadas
abiertas pueden contener sub-transacciones
cerradas, que no liberan resultados parciales, y
sub-transacciones abiertas que si liberan sus
resultados parciales.
TRANSACCIN MULTINIVEL
La transaccin multinivel es una variante de las
transacciones anidadas donde los nodos en un
rbol de transaccin corresponde a las
ejecuciones de operaciones a niveles particulares
de abstraccin en el sistema de capas.
Es decir, todos los arboles de transaccin tiene la
misma altura, la cual es igual al numero de
niveles en la arquitectura del sistema y todos los
nodos hoja en una rbol de transaccin estn al
mismo nivel.
TRANSACCIONES MULTINIVEL
Ejecucin concurrente de transacciones multinivel
EJEMPLO DE UN MODELO DE
TRANSACCIN MULTI-NIVEL:
Calendarizador serializable sin conflicto
T7: T71, incrementa a balx en 5

T72, decrementa en 5 a baly
T8: T81, incremente a baly en 10
T82, decrementa a balx en 2
Como las operaciones de adicin y sustraccin son

conmutativas,
se
pueden
ejecutar
estas
subtransacciones en cualquier orden y el
resultado ser siempre correcto.
Considere el calendario dado abajo, determine si

existe conflicto en la Serializacion del
calendarizador y divida las transacciones en el
calendario en subtransacciones que puedan ser
ejecutadas concurrentemente que permita
generar el resultado correcto.
La grafica de precedencia es como sigue
Por tanto el calendario no tiene conflicto al ser

serializable.
La siguiente divisin en subtransacciones es la

siguiente:
Dado
que
la
adicin,
substraccin
y
multiplicacin son conmutativas, entonces se
puede ejecutar las transacciones en cualquier
orden y el resultado correcto ser posible de
cualquier manera.

Bases de Datos Distribuidas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bases de Datos Distribuidas

Caricato da

Copyright:

Formati disponibili

ADMINISTRACIN DE

Recopil: Dra. Mara del Pilar Angeles

Recopil: Dra. Mara del Pilar Angeles

Centralizado: Las sentencias

Recopil: Dra. Mara del Pilar Angeles

control de concurrencia administra la

control de concurrencia se encarga de

Recopil: Dra. Mara del Pilar Angeles

Recopil: Dra. Mara del Pilar Angeles

Manejar mltiples copias de los elementos de

El mtodo de recuperacin debe cuidar que una

Recopil: Dra. Mara del Pilar Angeles

Fallos de sitios individuales: EL Manejador

Recopil: Dra. Mara del Pilar Angeles

Fallo de enlaces de comunicacin: El sistema

Recopil: Dra. Mara del Pilar Angeles

Confirmacin distribuida: Puede haber

Recopil: Dra. Mara del Pilar Angeles

Deadlock distribuido: Puede ocurrir un

Recopil: Dra. Mara del Pilar Angeles

CONTROL DE CONCURRENCIA DISTRIBUIDO

La idea es designar una copia determinada de

Recopil: Dra. Mara del Pilar Angeles

TCNICA DE SITIO PRIMARIO:

En este mtodo se designa un solo sitio primario

Por tanto todos los bloqueos se mantienen en ese

Recopil: Dra. Mara del Pilar Angeles

TCNICA DE SITIO PRIMARIO:

Por ej. Si todas las transacciones siguen e

Sin embargo como todas las solicitudes de

Recopil: Dra. Mara del Pilar Angeles

SITIO PRIMARIO CON SITIO DE RESPALDO

Este enfoque busca subsanar la segunda

Recopil: Dra. Mara del Pilar Angeles

SITIO PRIMARIO CON SITIO DE RESPALDO

Sin embargo, el proceso de adquisicin de

Recopil: Dra. Mara del Pilar Angeles

TCNICA DE COPIA PRIMARIA

Este mtodo intenta distribuir la carga de la

Recopil: Dra. Mara del Pilar Angeles

ELECCIN DE UN NUEVO SITIO

Recopil: Dra. Mara del Pilar Angeles

ELECCIN DE UN NUEVO SITIO

En los mtodos que usan sitios de respaldo, el

Recopil: Dra. Mara del Pilar Angeles

ELECCIN DE UN NUEVO SITIO

Si el sitio de respaldo X esta a punto de

Sin embargo, si no hay sitio de respaldo, o si

Recopil: Dra. Mara del Pilar Angeles

ELECCIN DE UN NUEVO SITIO

Recopil: Dra. Mara del Pilar Angeles

CONTROL DE CONCURRENCIA DISTRIBUIDO

En el mtodo de votacin, no hay copia

Cada copia mantiene su propio candado y puede

Recopil: Dra. Mara del Pilar Angeles

CONTROL DE CONCURRENCIA DISTRIBUIDO

Si la mayora de las copias otorgan un candado a

Si una transaccin no recibe la mayora de los

Recopil: Dra. Mara del Pilar Angeles

CONTROL DE CONCURRENCIA DISTRIBUIDO

El mtodo de votacin se considera un mtodo de

Recopil: Dra. Mara del Pilar Angeles

Recopil: Dra. Mara del Pilar Angeles

GRAFICA DE ESPERA LOCAL (LWFG)