Procesamiento de Transacciones

Contenido
Procesamiento de
Transacciones
„
… Sincronización
… Transacciones
„
„
Mecanismos de Control de Concurrencia
Control de Concurrencia:Problemas
… Equivalencia
Material basado en los capítulos 12 y 13
del libro: Sistemas Distribuidos. CyD. G.
Coulouris, J. Dollimore and T. Kindberg.
Contenido
Definiciones Básicas
… Operaciones
Secuencial
Conflictivas
Contenido
„
de Concurrencia a través de bloqueos
Optimista de la Concurrencia
… Ordenación por marcas de tiempo
Transacciones Distribuidas
… Control
… Sistema
… Control
… Transacciones
Manejador de Transacciones
Planas y Anidadas
… Commit y Abort en un Sistema Distribuido
… Control de Concurrencia
Por Bloqueo
Optimista
„ Marcas Temporales
„
„
Contenido
„
Recuperación de Transacciones
Transacciones
„
En algunas situaciones, los clientes necesitan
que una secuencia de solicitudes separadas al
servidor: buscarcuenta, deposita, extrae,
obtenerBalance sean atómicas:
… Estén
libres de interferencia por operaciones de otros
clientes
… Todas las operaciones se deben completar con éxito
o no tener ningún efecto si el servidor falla.
1
Transacciones
Transacciones
Provienen de los sistemas de Gestión de
BD. En este contexto una transacción es
la ejecución de un programa que accede a
las BD.
„ Fueron introducidas en los sistemas
distribuidos en la forma de servidores de
archivos transaccionales (secuencia de
operaciones sobre archivos)
„
„
„
Una transacción es una colección de acciones
que hacen transformaciones de los estados de
un sistema preservando la consistencia del
sistema
El manejo de transacciones puede venir como
parte del middleware. Por ejemplo, CORBA,
proporciona la especificación para un servicio
de transacciones sobre objetos.
Transacciones
Transacciones
Una transacción aplica a datos recuperables, puede
estar formada por operaciones simples o
compuestas y su intención es que sea atómica.
Hay dos aspectos que se deben cumplir para
lograr la atomicidad:
1. Todo-o-nada: si una transacción termina
exitosamente, los efectos de todas sus
operaciones son registrados en los objetos, o si
falla o es abortada deliberadamente, no tiene
ningún efecto.
La propiedad todo-o-nada tiene otros dos
aspectos en sí misma:
Atomicidad ante fallas: los efectos son
atómicos aun cuando el servidor falla.
Los datos que se mantienen en disco
deben sobrevivir ante la falla del
servidor.
Durabilidad: después que una
transacción ha terminado exitosamente,
todos sus efectos son salvados en
almacenamiento permanente.
Transacciones
2. Aislamiento: cada transacción debe ser
ejecutada sin interferencias de otras
transacciones, es decir, los resultados
intermedios de una transacción no deben
ser visibles a otras transacciones.
Propiedades ACID
„
„
Estas propiedades también son conocidas
como propiedades ACID
„
„
Atomicidad (Atomicity): todo o nada.
Consistencia (Consistency): una transacción
hace pasar el sistema de un estado consistente
a otro. Es generalmente responsabilidad de los
programadores de servidores y clientes el
asegurar que los datos queden en un estado
consistente.
Aislamiento (Isolation)
Durabilidad (Durability)
2
Propiedades ACID
„
Para soportar la atomicidad ante fallas y la
durabilidad, los objetos de datos deben ser
recuperables (estar disponibles en
almacenamiento permanente).
„
Cuando cae un servidor (falla de hardware o
software) los cambios de todas las
transacciones que culminaron deben estar
disponibles en el almacenamiento permanente.
Cuando el servidor sea reemplazado se
recuperarán los objetos para reflejar TODO o
NADA.
Propiedades ACID
„
„
Condiciones de Terminación
„
„
C
Una transacción siempre termina, aun en la
presencia de fallas. Si una transacción termina
de manera exitosa se dice que la transacción
hace un commit (consumación)
Si la transacción se detiene sin terminar su
tarea, se dice que la transacción aborta.
Cuando la transacción es abortada, su
ejecución se detiene y todas las acciones
ejecutadas hasta el momento se deshacen
(undone) regresando a la base de datos al
estado antes de su ejecución. A esta operación
también se le conoce como rollback.
Estructura de un Sistema de Manejo de
Transacciones
El manejador de transacciones
(Coordinador) dá a cada transacción un
identificador TID
„ Operaciones disponibles al Cliente:
„
tid BeginTransaction() para el comienzo de una
transacción, devuelve el TID
EndTransaction(tid), devuelve abort o commit dependiendo
si la transacción
se ha podido o no realizar
Abort(tid): El cliente puede abortar la transacción.
Un servidor que soporta transacciones debe
sincronizar las operaciones para asegurar que
se satisface el requisito de aislamiento. Una
forma de hacerlo es serializando o
secuencializando las operaciones. Esto puede
ser inaceptable desde el punto de vista del
desempeño.
La idea de los servidores es maximizar la
concurrencia, se permitirá entonces que se
entremezclen las transacciones (o sus
componentes), si el efecto es el mismo que si se
ejecutarán secuencialmente. Es decir son
secuencialmente equivalentes.
C
C
Estructura de un Sistema de
Manejo de Transacciones
„
TPS
Transaction
Manager
„
scheduler
Data Manager
Recovery
Manager
Cache
Manager
„
El Manejador de Transacciones
valida las peticiones de los
clientes y pasa la transacción al
planificador.
El Planificador usa alguna
estrategia para permitir una
ejecución concurrente que sea
secuencialmente equivalente.
Manejador de Datos: transferir
los datos a memoria principal,
escribir actualizaciones,
recuperarse ante fallas.
Estructura de las Transacciones
„
Planas: consisten de una secuencia de
operaciones primitivas encerradas entre
las palabras clave Begin Transaction y
End Transaction. Por ejemplo,
Begin_transaction Reservación
. . .
End transaction
3
Estructura de las Transacciones
„
T: Transacción de Niver Superior
Anidadas: las operaciones de una
transacción pueden ser transacciones
. Por ejemplo,
Begin_transaction Reservación
...
Begin_transaction Vuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
Commit
T1:
T2:
Commit provisional
T11
Commit provisional
T12
Abort
T21
Commit provisional
Commit provisional
T211
Commit provisional
end {Hotel}
End_transaction Reservación
Transacciones Anidadas
„
„
Una transacción anidada dentro de otra
transacción conserva las mismas propiedades
que la de sus padres, esto implica, que puede
contener así mismo transacciones dentro de
ella.
Existen restricciones obvias para una
transacción anidada:
Transacciones Anidadas
„
… Debe
empezar después que su padre y debe
terminar antes que él.
… El commit de una subtransacción es condicional al
commit de su padre, en otras palabras, si el padre de
una o varias transacciones aborta, las
subtransacciones hijas también serán abortadas.
Transacciones Anidadas
„
Las transacciones pueden hacer commit o
abort de forma independiente. Cuando
una subtransacción aborta, la transacción
padre puede elegir una sub-transacción
alternativa para completar su tarea.
Las transacciones anidadas proporcionan un
nivel más alto de concurrencia entre
transacciones. Ya que una transacción consiste
de varios transacciones, es posible tener más
concurrencia dentro de una sola transacción.
Las transacciones de un mismo nivel se pueden
ejecutar en forma concurrente pero sus accesos
se deben secuencializar.
Transacciones Anidadas
„
Reglas para el commit de transacciones
anidadas:
… Una
transacción puede hacer commit o abort
sólo después que han terminado las
transacciones hijas.
… Cuando una subtransacción finaliza, decide
de forma independiente si hace un commit
provisional o aborta. Una decisión de abortar
es definitiva.
4
Transacciones Anidadas
„
T: Transacción de Niver Superior
Reglas para el commit de transacciones
anidadas:
un padre aborta, todas las subtransacciones
abortan (aún cuando éstas hayan realizado un
commit provisional)
… Cuando una subtransacción aborta, el padre puede
decidir abortar o no.
… Si las transacciones de alto nivel hacen COMMIT, se
pueden consumar también todas las
subtransacciones que hayan realizado un COMMIT
provisional. Los efectos de una subtransacción no
son permanentes hasta que no se consuma la
transacción de nivel superior
Commit
T1:
… Cuando
Control de Concurrencia
T2:
Commit provisional
T11
Commit provisional
T12
Abort
T21
Commit provisional
Commit provisional
T211
Commit provisional
„
Control de Concurrencia: Problemas que generan las
operaciones conflictivas ejecutándose concurrentemente
Actualizaciones Perdidas
T:
balance = b.obtenBalance();
b.ponBalance(balance*1.1)
a.Extrae(balance/10)
Las versiones provisionales se transfieren
a los objetos sólo cuando una transacción
hace commit; en este caso se transfieren
también a memoria permanente.
„ Cuando una transacción aborta, sus
versiones provisionales se borran.
„
U:
balance = b.obtenBalance();
b.ponBalance(balance*1.1)
c.Extrae(balance/10)
balance = b.obtenBalance(); 200$
balance = b.obtenBalance(); 200$
b.ponBalance(balance*1.1) 220$
b.ponBalance(balance*1.1) 220$
a.Extrae(balance/10)
c.Extrae(balance/10)
El valor final de B ha debido ser 242$, no 220$. U leyó un valor antes de que T
lo actualizara.
„
Recuperaciones Inconsistentes
V:
„
El problema viene por paralelizar o
pretender que las 2 transacciones se
ejecuten concurrentemente cuando deben
ejecutarse en forma secuencial.
W:
Unasucursal.totalSucursal();
a.extrae(100)
b.Deposita(100)
/* El valor inicial de ambas cuentas es
200 */
a.extrae(100)
$100
Total = a.obtenbalance();
total = total + b.balance(); // total=300
total = total + c.balance():
b.Deposita(100)
$300
W ve el valor nuevo de a y el Valor viejo de b. No se está cumpliendo la
propiedad de isolation.
5
Control de Concurrencia
Control de Concurrencia: Sol. a
actualizaciones perdidas.
Operaciones conflictivas: 2 operaciones son conflictivas
cuando sus efectos combinados dependen del orden en el cual
fueron ejecutadas.
balance = b.obtenBalance(); 200$
b.ponBalance(balance*1.1) 220$
balance = b.obtenBalance(); 220$
b.ponBalance(balance*1.1) 242$
a.Extrae(balance/10)
c.Extrae(balance/10)
-Se puede conseguir equivalencia secuencial secuenciando el acceso al objeto.
-La tabla es un ejemplo de secuenciamiento + cierto grado de concurrencia.
•
Se consideran conflictivas las siguientes operaciones:
read
read
no conflictivas
read
write
conflictivas
write
write
conflictivas
• Cuando dos o más transacciones son conflictivas es necesario
su serialización para asegurar la consistencia de los datos
después de su ejecución.
Control de Concurrencia
Control de Concurrencia
Equivalencia secuencial:
Para cualquier par de transacciones es posible
determinar un orden de operaciones conflictivas
sobre objetos accedidos por ambas. La
equivalencia secuencial se logra de la siguiente
forma:
„
„
a. - Todos los accesos de una transacción a un
objeto particular (operaciones conflictivas)
deben secuencializarse con respecto a su
acceso por otras transacciones.
Equivalencia secuencial:
b. Todos los pares de operaciones conflictivas
de dos transacciones se deben ejecutar en el
mismo orden sobre los objetos a los que ambas
acceden. Se requiere:
T acceda i antes que U y T accede j antes que U
U acceda a i antes que T y U acceda a j antes que T
Control de Concurrencia
Control de Concurrencia
Transacciones
T: x=lee(i); escribe(i,10); escribe(j,20)
U: y=lee(j); escribe(j,30); z=lee(i)
A
B
C
A
B
C
Operaciones conflictivas
Delay
Ejecución
x = lee(i)
escribe(i,10)
y = lee(j)
Escribe(j,30)
escribe(j,20)
Operaciones compuestas
Z=lee(i)
No es secuencialmente equivalente porque los pares de operaciones conflictivas
No se hacen en el mismo orden en todos los objetos. Aunque si se cumple la
Primera condición.
Serialización de operaciones
conflictivas
6
Control de Concurrencia: Problemas que
generan las operaciones conflictivas
„
Recuperaciones Inconsistentes
V:
W:
Unasucursal.totalSucursal();
a.extrae(100)
b.Deposita(100)
Sol. Del problema de
Recuperaciones Inconsistentes.
V:
a.extrae(100)
b.Deposita(100)
W:
$100
$300
Total = a.obtenbalance();
total = total + b.balance;
total = total + c.balance():
/* El valor inicial de ambas cuentas es
200 */
a.extrae(100)
$100
Total = a.obtenbalance();
total = total + b.balance;
total = total + c.balance():
b.Deposita(100)
$300
W ve el valor nuevo de a y el Valor viejo de b. No se está cumpliendo la
propiedad de isolation. V accede a antes que W. V accede a b después de W.
Control de Concurrencia: Accesos
secuencialmente equivalentes.
„
„
Los protocolos intentan secuencializar los
accesos.
Se utilizan tres aproximaciones:
Control de Concurrencia
Las transacciones pueden abortar, ante esta situación
surgen otros problemas: lecturas sucias y escrituras prematuras
Lecturas Sucias
Transacción T
Transacción U
a.getBalance() (110$)
a.deposita(20) (130$)
commit
… Bloqueo.
de Concurrencia Optimista
… Ordenación por marcas de tiempo.
… Control
„
No obstante pueden aparecer problemas aún en
presencia de ejecuciones secuencialmente
equivalentes.
Lectura Sucia
a.getBalance() (100$)
a.depositar(10) (110$)
aborta
Se restaura el valor de a a 100. U tomó el valor 110$ que ahora no es
válido.
- La estrategia para la recuperación es retrasar la acción de
commit de U hasta que T finalice
- Esto conlleva a la posibilidad de Abortos en Cascada (si T
aborta, U debe abortar también)
Control de Concurrencia
Control de Concurrencia
Escrituras Prematuras
T:
a.ponBalance(105)
„
Una forma de evitar abortos en cascada
es sólo permitir a las transacciones leer
objetos que fueron escritos por
transacciones consumadas.
a.ponBalance(105)
U:
b.ponBalance(110)
100$
105$
a.ponBalance(110)
105$
110$
Algunos sistemas de BD implementan la acción Abort restaurando las
imágenes Anteriores.
Si U aborta y T se consuma el balance debe ser de 105$. Correcto.
U se consuma y T Aborta: El balance debería estar en 110$, pero se coloca
la imagen anterior a T que es 100$. La escritura de U es prematura, antes
de que T haga su commit.
7
Control de Concurrencia
„
Para garantizar resultados correctos en un
esquema de recuperación que utiliza
imágenes anteriores, las operaciones de
escritura se deben atrasar hasta que las
transacciones anteriores que actualizaron
los mismos objetos hayan hecho commit o
abort (U no debería escribir)
Control de Concurrencia
„
„
„
Control de Concurrencia
Para que un servidor está en capacidad de
deshacer cambios si una transacción aborta,
debe diseñarse de forma que las
actualizaciones puedan ser eliminadas.
Todas las operaciones de actualización se
hacen sobre versiones provisionales de los
objetos en memoria volátil.
A cada transacción se le proporciona su
conjunto privado de versiones provisionales
de los objetos que ha alterado.
Control de Concurrencia: Bloqueos
balance = b.obtenBalance(); 200$
b.ponBalance(balance*1.1) 220$
balance = b.obtenBalance(); 220$
b.ponBalance(balance*1.1) 242$
a.Extrae(balance/10)
c.Extrae(balance/10)
-Se puede conseguir equivalencia secuencial secuenciando el acceso al objeto.
-La tabla es un ejemplo de secuenciamiento + cierto grado de concurrencia.
-Una forma sencilla de secuenciar es a través del uso de bloqueos exclusivos.
La ejecución de las transacciones se
llama estricta si las lecturas o escrituras
de los objetos se retrasa hasta que
todas las transacciones que
previamente escribieron el objeto hayan
hecho commit o abort. La ejecución
estricta de las transacciones hace
cumplir la propiedad de aislamiento.
Contenido
„
Mecanismos de Control de Concurrencia
… Control
de Concurrencia a través de bloqueos
Optimista de la Concurrencia
… Ordenación por marcas de tiempo
… Comparación de métodos.
… Control
„
Recuperación de Transacciones
Control de Concurrencia: Bloqueos
Nivel de granularidad: tiene que ver con el tamaño del
objeto o dato que se está bloqueando. A mayor
granularidad (mayor fineza del grano), más pequeño es el
tamaño del objeto.
Mientras mayor sea la fineza del grano, mejor será el
grado de paralelismo/concurrencia, pero mayor será la
complejidad del sistema.
El bloqueo puede ser a nivel de item, página, archivo, base
de datos (donde item representa el grano más fino y base
de datos corresponde al grano más grueso)
8
Control de Concurrencia:
Bloqueos
Control de Concurrencia: Problemas que
generan las operaciones conflictivas
Cada vez que un proceso necesita leer o
escribir en un objeto como parte de una
transacción, el objeto se bloquea hasta que
la transacción culmine exitosamente
(commit). Cualquier otra transacción que
desee hacer alguna operación sobre dicho
objeto tendrá que esperar hasta que él sea
desbloqueado.
„
„
„
Para lograr equivalencia secuencial, todos los
pares de operaciones conflictivas se deben
hacer en el mismo orden.
Para asegurar esto, no está permitido a una
transacción ningún nuevo bloqueo después que
ha liberado alguno.
Existen dos fases:
… Adquirir
… Liberar
Algoritmo de locking o bloqueo
Two Phase Locking: “obtención” y “liberación”
Durante la fase de “obtención”, la transacción trata de
obtener todos los locks que necesite. Si no es posible
obtener alguno, entonces espera.
La segunda fase comienza cuando la transacción libera
alguno de los locks, a partir de ese momento no podrá
solicitar ningún otro lock (si lo hace, será abortada).
Desventaja: si una transacción en la fase de liberación
había desbloqueado algunos objetos y los mismos
habían sido accedidos por otras transacciones antes de
que la primera hiciera commit, entonces las demás
transacciones deberían abortar (esto es abortos en
cascada). Pudiera ocurrir: lecturas sucias o escrituras
prematuras
Algoritmo de locking o bloqueo
Two Phase Locking
Fase de crecimiento
Algoritmo de locking o bloqueo
Para evitar esto, se mantienen todos los
bloqueos aplicados a los objetos hasta que la
transacción que los posee se consuma (commit)
o aborte. Esto se llama Bloqueo en dos fases
estricto.
La fase de “liberación” se realiza sólo cuando la
transacción hace commit
Ventaja: evita los abortos en cascada
Desventajas:
El nivel de paralelismo se degrada
En algunos casos es inadmisible.
Control de Concurrencia: Bloqueos
Strict Two Phase Locking
Fase de crecimiento
Fase de liberación
number of locks
number of locks
Time
bloqueos (Fase de crecimiento)
bloqueos (Fase de Acortamiento)
Fase de liberación
Se liberan
todos los
locks
Para mejorar la concurrencia, la
porción de objetos a la que se debe
secuenciar el acceso debe ser tan
pequeño como sea posible.
Problema de los lectores o escritores.
Time
9
Algoritmo de locking o bloqueo
lock otorgado
Ninguno
•
lock solicitado
read
OK - write OK
read
read
write
read Espera - write Espera
OK - write Espera
Se toma un lock de lectura, y se promueve a un bloqueo de
escritura cuando se va a escribir sobre el mismo objeto.
Cuando una transacción posterior desea leer, debe
esperar hasta que se libere el lock de escritura.
Una mejora: utilizar locks de escritura y locks de lectura para
ofrecer un mejor paralelismo al permitir que se realicen
concurrentemente transacciones que hagan operaciones no
conflictivas.
Algoritmo de locking o bloqueo
Para asegurar que se sigan las reglas
de solicitud de bloqueos para los
objetos , el cliente no tiene acceso a las
operaciones de bloqueo. Los locks son
adquiridos y liberados por el
administrador de transacciones. Todo lo
concerniente al control de concurrencia
es transparente para el programador.
Bloqueo para Transacciones
Anidadas
„
Algoritmo de locking o bloqueo
La primera regla se logra disponiendo que
cada bloqueo que adquiere una
subtransacción es heredado por su padre
cuando esta finaliza. Esto garantiza que
puedan mantenerse los bloqueos hasta
que se haya consumado o abortado la
transacción a nivel superior.
Bloqueo para Transacciones
Anidadas
„
El proposito de un esquema de bloqueo es
serializar el acceso a los objetos de modo que:
… 1.
Cada conjunto de transacciones anidadas sea la
única entidad a la que se debe impedir ver los efectos
de otro conjunto de transacciones anidadas
… 2. Se debe impedir que cada transacción en un
conjunto de transacciones anidadas observe los
efectos parciales de otras transacciones del conjunto.
Bloqueo para Transacciones
Anidadas
„
La segunda regla se hace cumplir así:
… No
se permite la ejecución concurrente de padre e
hijos. Si una transacción padre tiene un bloqueo
sobre el objeto, retiene el bloqueo mientras el hijo se
ejecuta. La transacción hijo adquiere temporalmente
el bloqueo.
… Se permite la ejecución concurrente de transacciones
al mismo nivel, por lo que cuando éstas accedan a
los mismos objetos el esquema de bloqueo debe
secuenciar el acceso.
10
Algoritmo de locking o bloqueo
El problema del algoritmo de bloqueo es que
puede ocasionar deadlocks o Interbloqueos.
T
U
a.Deposita()
bloqueo de escritura para A
b.extrae
Espera por U
Bloqueo en B
b.Deposita() bloqueo de escritura para B
a.extrae(200) Espera por T.
Bloquea en A
Interbloqueos
Condiciones para un bloqueo:
1.- Condición de exclusión mutua. Cada recurso está
asignado a un único proceso o está disponible.
2.- Condición de posesión y espera.Los procesos que
tienen, en un momento dado, recursos asignados con
anterioridad, pueden solicitar nuevos recursos.
3.- Condición de no apropiación. Los recursos otorgados
con anterioridad no pueden ser forzados a dejar un proceso. El
proceso que los posee debe liberarlos en forma explícita.
4.- Condición de espera circular.Debe existir una cadena
circular de dos o más procesos , cada uno de los cuales espera
un recurso poseído por el siguiente miembro de la cadena.
Tratamiento de Interbloqueos
Políticas frente a los bloqueos:
1.- Detectar: dejar que suceda y luego recuperarse.
Poseído por
Espera por
R1
T
T
U
Espera por
U
R2
Poseído por
Grafo de Espera Circular: Si hay un ciclo en el grafo significa
que hay interbloqueo.
Tratamiento de Interbloqueos
Políticas frente a los bloqueos:
1.- Detectar:
Se pueden detectar a través de los grafos.
Una vez detectado el ciclo se debe escoger una
transacción y abortarla. La elección de la transacción
a abortar no es sencilla. Un factor que puede ser
tomado en cuenta es su edad.
La presencia de ciclos en el grafo se puede detectar
cada vez que se añade un arco o cada cierto tiempo
para disminuir el overhead.
3.- Evitar que estructuralmente sea posible el deadlock,
es decir, asegurar que al menos una de las cuatro
condiciones no se cumpla. (EM, NApropiación, H and
W, Circular Wait)
4.- Predecir: Algoritmo del Banquero: Se necesita
conocer los requerimientos de recursos del proceso.
(No es aplicable en sistemas distribuidos por su
complejidad de conocer los requerimientos de
recursos de los procesos con anterioridad).
Algoritmos de Prevención
• Se basan en asignar a cada transacción un timeout:
• A cada bloqueo se le proporciona un tiempo
limitado en el que es invulnerable.
•Después de ese tiempo es vulnerable.
•Si ninguna transacción está compititnedo por el
objeto, un objeto con bloqueo vulnerable continua
bloqueado.
•Sin embargo, si cualquier otra transacción está
esperando por acceder a un objeto con un bloqueo
vulnerable, se rompe el bloqueo y se reanuda la
transacción que esperaba. La transacción cuyo
bloqueo se ha roto, normalmente aborta.
11
Bloqueos
Contenido
Causan overhead en el manejo de
bloqueos y en los algoritmos de
prevención o deteccción
„ Disminuyen la concurrencia.
„ Otros esquemas (Ver en el material de
apoyo)
„
„
… Bloqueo
de Versiones
… Jerárquico
Algoritmo Optimista
Se permite que las transacciones procedan como si no
hubiera posibilidad de conflicto con otras transacciones hasta
que el cliente complete su tarea y solicite un EndTransaction.
Cuando aparece un conflicto se abortará la transacción.
Las modificaciones/accesos se hacen sobre espacios
privados y se lleva registro de los datos que han sido
modificados/accedidos. Al momento del commit, se chequea
que los espacios privados sean válidos, de no serlos, se
aborta la transacción.
A toda transacción se le asigna un identificador (orden
secuencial ascendente).
Algoritmo Optimista
Mecanismos de Control de Concurrencia
… Control
de Concurrencia a través de bloqueos
Optimista de la Concurrencia
… Ordenación por marcas de tiempo
… Comparación de métodos.
… Control
„
Recuperación de Transacciones
Algoritmo Optimista
Cada transacción cumple tres fases:
Trabajo:Todos los reads se ejecutan inmediatamente
sobre la última versión “consumada” del dato. Los
writes crean versiones tentativas. Se mantiene un
conjunto de lectura (datos leídos) y un conjunto de
escritura (versiones tentativas de los datos).
No hay posibilidad de “lecturas sucias”, sólo se leen
valores consumados.
Validación: Ante la solicitud de un commit, se valida si
la transacción realizó operaciones conflictivas con
otras transacciones. Si la validación tiene éxito se
puede hacer COMMIT. Si falla, se debe usar alguna
forma de resolución de conflictos (abortar alguna de
las transacciones)
Algoritmo Optimista
Fase de validación:
Escritura: Si la transacción es validada,
todos los cambios hechos sobre los espacios
privados se actualizan en las versiones
originales.
Ante el End_transaction, a cada transacción se le asigna
un número (secuencial ascendente, i) que define su
posición en el tiempo.
12
Algoritmo Optimista
Fase de validación:
Algoritmo Optimista
Validación hacia atrás:
La validación se basa en las siguientes reglas :
Tv
Ti
1. write read
Los reads de las Ti se realizaron antes que la
validación (por tanto escritura) de Tv, entonces se
cumple la regla 1.
Regla (i<v)
Ti no debe leer datos escritos por Tv
Sólo se valida la regla 2 para cada Ti:
2. read write Tv no debe leer datos escritos por Ti
valid= true;
for (Ti=startTn+1;Ti<=finishTn,Ti++) {
if (“read_set” of Tv intersects “write_set” Ti)
valid=false;
}
3. write write
Ti no debe escribir datos que está escribiendo o
haya escrito Tv y
Tv no debe escribir datos que está escribiendo o
haya escrito Ti
Simplificación: fases de validación y escritura son
secciones críticas (muy cortas), se supondrá que no pueden
solaparse 2 transacciones en estas fases; se satisface la
regla 3. Sólo hay que validar las reglas 1 y 2
Algoritmo Optimista
Algoritmo Optimista
Validación hacia atrás:
Validación hacia atrás:
startTn: Ti más grande asignado a una transacción
committed al momento que Ti entra a su fase de trabajo.
finishTn: Ti más grande asignado al momento que Ti
entra a su fase de validación
Sólo es necesario validar los conjuntos de lectura. Las
transacciones que sólo hacen escritura no se validan (lo
que ella escriba lo validarán otras transacciones mayores
posteriormente).
Transacciones
anteriores committed
T1
T2
T3
Transacción en validación
activa1
Si Tv no es válida, se aborta
Tv
activa2
Validación
Trabajo
Escritura
Algoritmo Optimista
„
Validación hacia atrás: precisa que los
conjuntos de escritura de las versiones
antiguas de los objetos ya consumadas sean
retenidas hasta que no hayan transacciones
solapadas, aún no validadas, con la que
pudieran entrar en conflicto. En un entorno con
transacciones largas, el mantener estos
conjuntos puede ser un problema.
Algoritmo Optimista
„
Validación hacia adelante: el conjunto de
escritura de Tv se compara con el
conjunto de transacciones activas que se
solapan, aquellas que están aún en su
fase de trabajo.
13
Algoritmo Optimista
Fase de validación:
Algoritmo Optimista
Validación hacia adelante:
La validación se basa en las siguientes reglas :
Tv
Ti
Se satisface la regla 2 porque las transacciones activas no
escriben mientras que Tv no se ha completado.
Regla (v<i)
1. write read
Ti no debe leer datos escritos por Tv
Sólo se valida la regla 1 para cada Ti: se compara el
conjunto de escritura de Tv con los conjuntos de lectura
de las transacciones activas.
2. read write Tv no debe leer datos escritos por Ti
3. write write
Ti no debe escribir datos que está escribiendo o
haya escrito Tv y
valid= true;
for (Tid=activa1;Tid<=activaN,Tid++) {
if (“write_set” of Tv intersects “read_set” of Ti)
valid=false;
}
Tv no debe escribir datos que está escribiendo o
haya escrito Ti
Algoritmo Optimista
Validación hacia delante:
Algoritmo Optimista
Validación hacia adelante:
activaX: Representan transacciones que aún no han
entrado a la fase de validación
Las transacciones que sólo hacen lecturas no requieren
ser validadas
Si Tv no es válida:
Abortar las activas y consumar Tv
Abortar Tv
Transacciones
anteriores committed
T1
T2
T3
Transacción en validación
activa1
Tv
activa2
Validación
Trabajo
Escritura
Algoritmo Optimista
Desventajas:
Hay posibilidad se inanición: una transacción puede
abortar indefinidas veces y no se contempla un
mecanismo para evitarlo.
Este algoritmo no serviría para nada en sistema con
transacciones largas, muchas transacciones en
conflicto.
Algoritmo por Marcas de Tiempo
Las operaciones se validan al momento de ser ejecutadas.
Cuando una transacción comienza, se le asigna un
timestamp
La regla de ordenación básica por marca de tiempo está
basada en los conflictos de operación:
Una solicitud de una transacción para escribir un objeto
es válida sólo si ese objeto fue leído y escrito por
última vez por transacciones anteriores en el tiempo.
Una petición de lectura a un objeto es válida sólo si el
objeto fue escrito por última vez por una transacción
anterior.
14
Algoritmo por Marcas de Tiempo
Se trabaja con versiones tentativas. Las versiones
tentativas de los objetos son consumadas en el orden
determinado por las marcas de tiempo de las transacciones
que las realizaron.
Algoritmo por Marcas de Tiempo
Para saber cuando una operación de escritura es válida se
aplica el siguiente algoritmo:
Sea Tj una transacción que desea hacer una operación de
escritura sobre el objeto D.
Cada item de datos tiene asociado:
If ((Tj >= Max (Tread en D)) &&
(Tj > write_commit en D))
Proceder con el write sobre una versión tentativa
nueva, con marca de tiempo Tj
else // write is too late
Un timestamp de escritura (Twrite_commit), un timestamp
de lectura (Tread) y un conjunto de versiones tentativas con
su propio timestamp
Un write aceptado genera una versión tentativa
Abortar Tj;
Un read se dirige a la versión con el máximo timestamp
menor que el timestamp de la transacción
Algoritmo por Marcas de Tiempo
Regla de escritura (No se muestran las marcas de lectura)
a) T3->write
b) T3-> write
antes T2
antes T1
después T2
después T1
T3
c) T3->write
antes T1
después T1
T4
T3 T4
T2
Sea Tj una transacción que desea hacer un read sobre el objeto
D.
If ((Tj > Max (Write_Commit en D))
Sea Ds la versión de D con la máxima marca de tiempo de
escritura menor a Tj (commited o no)
Si se ha consumado Ds: realiza la operación de lectura.
Si no, espera hasta que la transacción que hizo la versión
Ds haga commit o abort.
else // write is too late
Versión
committ
T2 T3
d) T3-> write
antes T4
Algoritmo por Marcas de Tiempo
Para saber cuando rechazar o aceptar inmediatamente una
operación de lectura
Versión
tentativa
Abortar Tj;
T3 Aborta
después T4
Algoritmo por Marcas de Tiempo
Algoritmo por Marcas de Tiempo
Regla de lectura
a) T3->read
T2
read se ejecuta
inmediatamente
Seleccionado
(Ds)
c) T3->read
T1 T2 read espera
b) T3-> read
Seleccionado
(Ds)
d) T3-> read
T4
Las versiones commit (consumadas) de
cada objeto deben crearse en el orden de
las marcas de tiempo.
„ Un coordinador necesita esperar, a veces,
que se completen las transacciones
anteriores antes de escribir todas las
versiones consumadas de los objetos.
„
read se ejecuta
T2 T4
inmediatamente Versión
committ
Versión
tentativa
T3 Aborta
Seleccionado
(Ds)
15
La última marca de lectura
Corresponde a la transacción T
T
U
a
MTL
{}
MTE
S
beginT
Bal=b.obtenBalance()
b.ponBalance(bal*1.1)
a.Extrae()
Commit
BeginT
Bal=b.obtenBalance()
Espera por T
….
…
Bal=b.obtenBalance()
b.ponBalance()
b
c
Ejercicio
MTL MTE
{}
S
{T}
S,T
MTL MTE
{}
S
T
U
T
BeginT
BeginT
escribe(i,55)
escribe(j,66)
S,T
T
X=lee(i)
Escribe(j,44)
T
{U}
U
BeginT
T,U
Commit
BeginT
Escribe(i,55)
Escribe(j,66)
commit
X=lee(i)
Escribe(j,44)
S,U
c.Extrae()
Corra el algoritmo de secuenciación por marcas de tiempo. Las marcas
de tiempo iniciales de lectura y escritura son t0.
S < T < U. En negritas se colocan las operaciones ya consumadas
Algoritmo por Marcas de Tiempo
T
U
BeginT
y = lee(k)
BeginT
Ejercicio
Un servidor gestiona los objetos a1, a2, …an. El servidor proporciona a sus clientes
Dos operaciones:
Escribe(i,55)
Escribe(j,66)
Lee(i) devuelve el valor de ai
Escribe(i,valor) asigna el valor “valor” a ai
x = lee(i)
Commit
Escribe(j,44)
Commit
Qué pasa cuándo va a terminar la transacción T si corremos el algoritmo
Optimista con validación hacia atrás, hacia adelante???
Las transacciones T y U se definen como sigue:
T: x= lee(i); escribe(j,44)
U: escribe(i,55); escribe(j,66)
1. Cómo funciona o escriba una secuencia de ejecución con bloqueo estricto de dos
fases.
2. Describa un solapamiento de las transacciones T y U en el que los bloqueos se
Liberan prontamente y se obtiene un efecto que no es secuencialmente
equivalente.
Contenido
Transacciones
Distribuidas
„
Transacciones Distribuidas
… Transacciones
Planas y Anidadas
y Abort en un Sistema Distribuido
… Control de Concurrencia
… Commit
Por Bloqueo
Optimista
„ Marcas Temporales
„
„
… Recuperación
16
Las transacciones distribuidas pueden ser planas o
anidadas.
Transacciones Distribuidas
Sus actividades involucran múltiples
servidores.
„ Se usa el término transacciones
distribuidas para referirse a transacciones
planas o anidadas que acceden a objetos
administrados por múltiples servidores.
Cliente:
begin_transaction
call X.x
call Y.y
call Z.z
end_transaction
„
X
Transacción Plana:
Un cliente realiza peticiones
a más de un servidor.
cliente
Las peticiones son secuenciales
Y
Z
Transacciones Distribuidas
X
M
Transacciones Anidadas
N
Sea una transacción distribuida donde el cliente transfiere
$10 de la cuenta A a C y $20 de B a D. Las cuentas A
y B están separadas en servidores X e Y y las cuentas
C y D están en el servidor Z.
T11
T1
T
T12
T21
Cliente
Y
T2
P
Transascción distribuida anidada: las transacciones
del mismo nivel son concurrentes. Si están en
Servidores distintos pueden ejecutarse en paralelo.
T22
Si la transacción se estructura como un conjunto de
cuatro transacciones anidadas, los cuatro
requerimientos ( dos depósitos y dos retiros) pueden
correr en paralelo y el efecto total es lograr mayor
rendimiento que una transacción simple ejecutando
las cuatro operaciones secuencialmente.
Procesamiento de transacciones
distribuidas
„
Un cliente comienza una transacción
enviando un begin_transaction a cualquier
servidor TPS. Éste se convierte en el
coordinador y los que se tengan que
contactar a partir de aquí se convierten en
participantes.
17
Coord.
Unirse
A
a.extrae(4)
beginTransaction
endTransaction
Procesamiento de transacciones
distribuidas
SucursalX
El coordinador que inició la transacción es el
responsable final de consumarla o abortarla.
Durante el progreso de una transacción el
coordinador registra la lista de referencias de
participantes, y cada participante registra una
referencia hacia el coordinador.
Unirse
B
b.extrae(3)
SucursalY
b.extrae(T,3)
Unirse
Cliente
C
Nota: el coordinador está en uno de los
Servidores, por ejemplo SucursalX
D
c.deposita(4)
d.deposita(3)
SucursalZ
Procesamiento de transacciones
distribuidas
La operación BeginTransaction devuelve el
TID. Los identificadores de las transacciones
deben ser únicos dentro del sistema
distribuido.
Una forma sencilla de obtener identificadores
únicos esto es que cada TID tenga dos
partes: el identificador del servidor (e.g.
dirección IP) y un número único dentro del
servidor.
Transacciones Distribuidas
Cuando una transacción distribuida termina, la
propiedad de atomicidad exige que todos los
servidores acuerden lo mismo (commit) o todos
aborten (abort). Existen protocolos para llegar a
compromisos (Two-Phase-Commit)
Las transacciones distribuidas deben ser globalmente
serializadas. Existen protocolos de control de
concurrencia distribuida.
Procesamiento de transacciones
distribuidas
„
Existen dos aspectos importantes a considerar
en las transacciones distribuidas:
… La
consumación de una transacción
de concurrencia
… Control
„
Se supone que existe una comunicación entre
TPSs a través de un protocolo de aplicación.
Estos protocolos se implementan sobre RPC o
pase de mensajes.
Protocolos de Consumación Atómica
Cuando el coordinador recibe un requerimiento
Commit de una transación, tiene que asegurar:
Atomicidad: Todos los nodos se comprometen con
los cambios o ninguno lo hace y cualquier otra
transacción percibe los cambios en todos los nodos
o en ninguno.
Aislamiento:Los efectos de la transacción no son
visibles hasta que todos los nodos hayan tomado la
decisión irrevocable commit o abort.
18
Consumación en una fase
„
Commit de una fase atómico
Una manera simple de completar una transacción
en forma atómica por el coordinador es
comunicar el requerimiento de commit o abort (por parte
del cliente)
a todos los participantes de la transacción y
mantenerse enviando el requerimiento hasta
que todos ellos respondan con un ACK indicando que han
realizado la tarea.
Consumación en Dos Fases
„
„
„
El protocolo no contempla que
la decisión de abortar venga de uno de los participantes. Sólo puede venir del
cliente.
Consumación en Dos Fases
„
En la segunda fase: El coordinador
recoge el resultado de las votaciones. Si
alguno de los participantes vota por
abortar, la decisión es abortar. Si todos los
participantes votan consumar, esta será la
decisión.
Permite que cualquier participante aborte su parte de la
transacción.
En la primera fase del protocolo cada participante
vota para que la transacción sea consumada o abortada.
Una vez que el participante ha votado commit, no se le
permite que aborte. Por lo tanto, antes de un
participante votar por commit debe asegurarse que
será capaz de llevar a cabo su parte del protocolo de
consumación, incluso si falla.
Se dice que un participante está en estado “preparado”
si finalmente será capaz de consumar la transacción en
proceso.
Consumación en Dos Fases
„
Si uno de los participantes o el Cliente
decide abortar (antes de la solicitud del
coordinador) se le informa al resto. No se
activa el protocolo de consumación.
Protocolo de Consumación en dos
Fases
Protocolo de Consumación en dos
Fases
Fase 1 (votación)
Fase 2 (finalización en función del resultado de la votación)
„ 3. El coordinador recoge los votos (incluyendo el propio)
… 1.
El Coordinador envía una petición (commit?) a
cada participante en la transacción
… 2. Cuando un participante recibe una petición
commit? Responde al Coordinador con su voto (si o
no). Antes de votar Sí se prepara para hacer commit
guardando los objetos en almacenamiento
permanente. Si el voto es No. El participante aborta
de forma inmediata.
…
…
„
Si no hay fallos y todos los votos son Sí, el coordinador decide
consumar la transacción y envía peticiones de COMMIT a cada
uno de los participantes.
En otro caso, el Coordinador decide abortar la transacción y
envía peticiones Aborta a todos los que votaron Sí.
4. Los participantes que han votado Sí están esperando
por una petición de Commit o Abort por parte del
Coordinador. Cuando se reciben uno de estos
mensajes, se actúa en función de ellos. En caso de
COMMIT se retorna al servidor:haveCOMMITTed.
19
Protocolo de Consumación en dos
Fases
„
„
Situación en la que un participante ha votado Sí y está
esperando para que el coordinador le informe el resultado de la votación
El protocolo podría fallar debido a la caída de
uno o más servidores o debido a un corte en la
comunicación.
Para cubrir la posibilidad de caidas, cada
servidor guarda la información correspondiente
al protocolo en un dispositivo de
almacenamiento permanente. Esta información
la puede recuperar un nuevo proceso que se
inicie para reemplazar al servidor caído.
Fallas en la Comunicación
Situación en la que un participante ha votado Sí y está
esperando para que el coordinador le informe el
resultado de la votación:
El participante está incierto frente al resultado y no puede
seguir adelante hasta que obtenga los resultados de la
votación por parte del coordinador. No puede decidir
unilateralmente, debe mantener los objetos. Envía un
mensaje al Coordinador de DameDecision. Cuando
obtiene la respuesta continua en el paso 4 del protocolo.
Si el Coordinador ha fallado el participante no podrá
obtener una decisión hasta que el servidor sea
reemplazado.
Acciones frente a un timeout
Acciones frente a un timeout
El participante ha realizado todas sus tareas
y aún no ha recibido el llamado Puede
Consumar?? (primera comunicación)
En este caso, como no se ha tomado
ninguna decisión el participante puede
decidir unilateralmente abortar.
El coordinador puede sufrir retrasos cuando está
esperando por los votos de los participantes.
Dado que no está decidido el destino de la
transacción, tras cierto periodo de tiempo
puede abortar. En ese momento, el
Coordinador anuncia su decisión a todos los
participantes que ya habían votado. Algunos
participantes retrasados pudieran votar Sí, sin
haber recibido el último mensaje del
coordinador. El coordinador ignora este Sí y el
participante pasa al estado incierto.
20
Transacciones Anidadas
T11
M
T1
T12
T11
X
T1
Aborta en M
Cons. Provisional (en X)
Cons. Provisional (en N)
T
T21
Cons. Provisional (en N)
T2
T
T12
Abortado (en M)
N
T22
Cliente
T21
Cons. Provisional (en P)
Y
T2
P
T22
Transacciones Anidadas
„
„
Cuando finaliza una subtransacción toma una
decisión independiente sobre si consumarse de
forma provisional (no es lo mismo que estar
preparado) o abortar. Una consumación
provisional es simplemente una decisión local y
no se guarda copia en un dispositivo de
almacenamiento permanente.
Las transacciones trabajan y, cuando terminan,
el servidor donde se encuentran registra
información sobre si se han consumado
provisionalmente o han abortado.
Transacciones Anidadas
Transacciones Anidadas
„
„
„
Cuando una transacción anidada se consuma
en forma provisional informa de su estado y del
estado de sus descendientes a su madre.
Cuando una transacción aborta, simplemente
informa de haber abortado a su madre.
Al final, la transacción a nivel superior recibe
una lista de todas las subtransacciones en el
árbol junto con el estado de cada una de ellas.
Transacciones Anidadas
T11
„
La transacción a nivel superior juega el
papel de Coordinador en el protocolo de
consumación en 2 fases.
Aborta en M
Cons. Provisional (en X)
T1
T12
Cons. Provisional (en N)
T
T2
T21
Cons. Provisional (en N)
Abortado (en M)
T22
Cons. Provisional (en P)
La lista de participantes consta de los servidores
de todas las subtransacciones que se hayan consumado
provisionalmente pero no tienen ascendentes que hayan
abortado: T, T1, T12
21
Transacciones Anidadas
Control de Concurrencia: Bloqueos
„
„
„
„
La transacción a nivel superior debe intentar
consumar lo que quede del árbol. A T1 y T12 se
les pedirá que voten para obtener el resultado.
Si votan consumar deben preparar las
transacciones guardando el estado de los
objetos en el dispositivo de almacenamiento
permanente.
La segunda fase es idéntica: se recogen los
votos y se informa a los participantes en función
del resultado.
„
„
„
En una transacción distribuida los bloqueos se
mantienen localmente (en el mismo servidor).
El administrador local de bloqueos puede decidir si
otorga un bloqueo o hace que la transacción que lo
requirió espere.
Sin embargo no puede liberar ningún bloqueo mientras
la transacción que los tiene no haya terminado (commit
o abort) en todos los servidores involucrados en la
transacción.
Cuando se usa el bloqueo para control de concurrencia,
los objetos permanecen bloqueados y no están
disponibles para otras transacciones durante el
protocolo de commit atómico, aunque una transacción
abortada libere sus bloqueos durante la primera fase del
protocolo.
Bloqueos
Bloqueos
Dado que los administradores de bloqueos en diferentes
servidores otorgan bloqueos independiente de los demás,
es posible que diferentes servidores impongan diferente
orden sobre las transacciones.
Se tiene T antes que U en un servidor y U antes
que T en
el otro.
„ Cuando se detecta una condición de
interbloqueo las transacciones son abortadas.
„ En este caso el coordinador será informado y
abortará las transacciones en los participantes
involucrados.
Considérese el siguiente entrelazado de las transacciones
T y U en los servidores X e Y:
T
U
Write(A) en X lock A
Write(B) en Y lock B
Read(B) en Y espera U
Read(A) en X espera por T
El objeto A está en el servidor X y el objeto B en el servidor Y
Algoritmos de Detección
Algoritmo Distribuido (Caza de
Arcos)
1.- Centralizado: basado en grafos de espera
Máquina 0
Máquina 1
Coordinador
Transacciones
A
Recursos
A
S
S
S
C
C
R
R
T
T
B
B
Cómo se mantiene el grafo en el coordinador ?
• Cada vez que ocurra una variación en su grafo notifica al coordinador .
• Periodicamente cada máquina notifica sus últimos cambios .
• Periodicamente el coordinador solicita la información.
Problema: Los 3 casos pueden conducir a un Deadlock falso.
En esta aproximación el grafo no se
construye en forma global, sino que cada
uno de los servidores implicados posee
información sobre alguno de sus arcos.
„ Los servidores intentan encontrar ciclos
mediante el envío de mensajes
denominados sondas.
„
Ejemplo: Si se pierden mensajes
Si B solicita a T y C libera a T y llega primero el mensaje de B al
coordinador, entonces el cree que hay deadlock.
22
Pasos del Algoritmo
„
„
Iniciación: Cuando un servidor percibe que una
transacción T, espera por un recurso que tiene
una transacción U (que está en otro servidor),
inicia el algoritmo enviando una sonda que
contiene el arco <T->U> al servidor que
contiene el objeto por el cual está bloqueada la
transacción U.
Si U está compartiendo el bloqueo (varias
transacciones acceden al mismo objeto), se
envía la sonda a los servidores responsables de
estas transacciones
Pasos del Algoritmo
„
Detección: Antes de reenviar la sonda, el
servidor comprueba si la transacción que
ha sido añadida, ej, T
Pasos del Algoritmo
Detección: consiste en recibir sondas y decidir si
se ha producido inter-bloqueo.
Por ejemplo, si un servidor recibe la sonda <T>U> (T espera por U, que tiene el bloqueo de un
objeto local), comprueba si U está también
esperando. Si es así, se añade a la sonda la
transacción por la que está esperando, ej, V.
<T->U->V>, y si V está esperando por un objeto
en otro sitio se vuelve a reenviar la sonda.
„
Pasos del Algoritmo
„
Resolución: cuando se detecta un ciclo, se
aborta una transacción en el ciclo para
romper el interbloqueo.
… <T->U->V->T>
Ha ocasionado un ciclo, si es así se ha
detectado un interbloqueo.
Algoritmo de Detección de
Bloqueos Distribuido
Algoritmo de Detección de
Bloqueos Distribuido
El coordinador de una transacción es responsable
de registrar si la transacción está activa o está
esperando por un objeto concreto, y los
participantes pueden obtener esta información
desde su coordinador. Los gestores de
bloqueos informan a los coordinadores cuando
las transacciones comienzan a esperar por
objetos, y en el momento que adquieren dichos
objetos para comenzar a estar activas.
Cuando se aborta una transacción para
romper un inter-bloqueo, el coordinador
informará a los participantes y se
eliminarán todos sus bloqueos, con el
efecto de que todos los arcos
relacionados con esta transacción se
eliminarán de los grafos espera-por
locales.
23
Control de Concurrencia Optimista
„
Recordar:
… Cada
transacción se valida antes de que se le
permita consumarse.
… Se asignan unos números de transacción al
comienzo de la validación y se establece un
orden o secuencia de acuerdo a estos
números.
Control de Concurrencia Optimista
En el caso de transacciones distribuidas
optimistas, cada servidor aplica en paralelo un
protocolo de validación. Esta es una extensión
de la validación hacia delante o hacia atrás para
permitir que varias transacciones estén en la
fase de validación (por lo que pueden tardar
estas fases en un entorno distribuido).
En esta extensión se debe comprobar tanto la
regla 3 como la regla 2 ó 1.
Control de Concurrencia Optimista
Una transacción Distribuida es validada
por una colección de servidores
independientes, cada uno de los cuales
valida las transacciones que acceden a
sus propios objetos.
„ La validación de todos los servidores tiene
lugar durante la primera fase del protocolo
de consumación de dos fases.
„
Control de Concurrencia Optimista
Sean las transacciones T y U entrelazadas,
las cuales acceden a los objetos A y B en
los servidores X e Y respectivamente:
T
Read(A) en X
Write(A)
Read(B) en Y
Write(B)
U
Read(B) en Y
Write(B)
Read(A) en X
Write(A)
Control de Concurrencia Optimista
Control de Concurrencia Optimista
Las transacciones acceden a los objetos en el orden T
antes que U en el servidor X y U antes que T en el
servidor Y.
Los servidores de transacciones distribuidas
deben evitar que suceda T antes que U en un
servidor y U antes que T en otro.
Sol: después de una validación local, se llevará a
cabo una validación global (antes de la
consumación). La validación global comprueba
que el orden en los servidores sea
secuencialmente equivalente.
„
Si se supone que T y U empiezan la validación al mismo
tiempo, el servidor X valida T primero y el servidor Y
valida U primero. No se cumple la equivalencia secuencial
„
„
24
Control de concurrencia con
ordenación de Marcas Temporales.
Time Stamps
„ En transacciones distribuidas se requiere que cada
coordinador genere una única marca de tiempo
global.
„ Se consigue la equivalencia secuencial consumando las
versiones de los objetos en el orden de las marcas
temporales de las transacciones que acceden a ellos.
„ Se requiere que cada coordinador genere marcas
temporales que sean globalmente únicas.
„ Esta marca de tiempo es dada al cliente por el primer
coordinador accedido por la transacción.
„ La marca de tiempo de la transacción se pasa al
coordinador de cada servidor en los cuales se
realizan operaciones de la transacción.
Time Stamps
Recuperación Distribuida
Se requiere que las marcas de tiempo
proporcionadas por un coordinador estén
aproximadamente sincronizadas con
aquellas que emiten otros coordinadores.
„ Las marcas se pueden mantener
sincronizadas mediante la utilización de
algoritmos de sincronización de relojes.
„
Recuperación Distribuida
Recuperación Distribuida
„
„
Los requisitos de persistencia y atomicidad ante
fallos se tratan mediante un único mecanismo:
el gestor de recuperación. Las tareas de un
gestor de recuperación son:
… Guardar
los objetos de todas las transacciones
consumadas en dispositivos de almacenamiento
permanente.
… Restaurar los objetos del servidor tras una caída.
„
„
Una marca temporal consta de: <marca
temporal local, identificador local del servidor>
Hemos supuesto que: Cuando un servidor está
en funcionamiento, mantiene todos sus objetos
en la memoria volátil y registra sus objetos
consumados en un archivo o archivos de
recuperación.
La recuperación consiste en restaurar el
servidor a partir de los dispositivos de
almacenamiento permanente y dejarlo con las
últimas versiones consumadas de los objetos.
… Reorganizar
el archivo de recuperación para
mejorar el rendimiento de la recuperación.
… Reclamar espacio de almacenamiento.
„
Se requiere que el gestor de recuperación
sea resistente a los fallos en los medios
(discos, etc). Se debe manejar al menos
una copia del archivo de recuperación.
25
Recuperación Distribuida
Recuperación Distribuida
Listas de Intenciones:
„ Durante el progreso de una transacción,
las operaciones de actualización se
aplican sobre un conjunto privado de
versiones tentativas de los objetos que
pertenecen a la transacción.
„ En cada servidor se guarda una lista de
intenciones para cada una de sus
transacciones activas.
„
„
Recuperación Distribuida
„
„
„
„
„
Recuperación Distribuida
En el protocolo de consumación de dos fases un
participante dice que está preparado para hacer
COMMIT.
Cuando un participante dice que está preparado
para hacer un commit, su gestor de
recuperación debe haber guardado en su
archivo de recuperación su lista de intenciones,
de tal forma que después pueda llevar a cabo el
commit, aún si fallara el servidor donde reside.
Registro Histórico
El archivo contendrá una instantánea reciente de los
valores de todos los objetos seguido de un historial de
las transacciones.
Cuando el servidor está preparado para consumar una
transacción, el gestor añade al archivo todos los objetos
en su lista de intenciones seguido por el estado actual
de la transacción (preparada).
Cuando una transacción se consuma o aborta, se añade
un nuevo registro con el estado de la transacción
La lista de intenciones de una transacción
contiene una lista de las referencias y los
valores de los objetos que son alterados durante
la transacción.
Cuando una transacción se consuma se utiliza
la lista de intenciones para identificar los
objetos afectados. Se reemplaza la versión
tentativa del objeto por una versión consumada.
„
Entradas del Archivo de Recuperación:
… Objeto:
el valor del objeto
de la transacción: Identificador de la
transacción, estado de la transacción (preparada,
consumada, abortada)
… Lista de intenciones: Identificador de la transacción y
una secuencia de intenciones, cada una de las
cuales consiste en: identificador del objeto, posición
en el archivo de recuperación.
… Estado
Registro Histórico
P0
Objeto: A
100
P1
Objeto: B
200
Objeto: C
300
P2
Objeto: A
80
Objeto: B
220
P3
Trans: T
Preparad
a
<A,P1>
<B,P2>
P0
P4
P5
P6
Trans:T
Objeto: C
Consumada 278
P7
Objeto: B
242
Trans: U
Preparad
a
<C,P5>
<B,P6>
P4
26
Registro Histórico
Registro Histórico
Tras una caída se aborta cualquier
transacción que no tenga el estado de
consumada.
„ Cada entrada del estado de una
transacción contiene un apuntador a la
posición en el archivo de recuperación de
la entrada que contiene el estado anterior
a la transacción.
„
„
Aproximaciones para restaurar:
… Desde
el comienzo del archivo. Las transacciones se
repiten en el orden en el cual fueron ejecutadas.
… Se recuperan los objetos leyendo el archivo de
recuperación hacia atrás. Se utilizan las
transacciones de estado consumadas para restaurar
objetos que no han sido restaurados. Cada objeto
sólo se restaura una vez.
Registro Histórico
„
P0
P1
Objeto: A
100
Objeto: B
200
Objeto: C
300
P2
Objeto: A
80
Objeto: B
220
P3
Trans: T
Preparad
a
<A,P1>
<B,P2>
P0
P4
P5
P6
Trans:T
Objeto: C
Consumada 278
P7
Objeto: B
242
„
„
„
… Comienza
en P7, concluye que U no se ha
consumado y sus efectos se deben borrar.
… Se mueve a P4 y concluye que T se había
consumado. Se mueve a P3 y restaura A y B
a partir de la lista de intenciones. Ya que no
ha restaurado C se mueve hacia P0, que es
el punto de control y restaura C.
Trans: U
Preparad
a
<C,P5>
<B,P6>
P4
Versiones Sombra
Es una forma alternativa de organizar el archivo
de recuperación.
Utiliza un mapa para localizar las versiones de
los objetos dentro de otro archivo.
Cuando una transacción está preparada para
hacer commit, se añaden los objetos cambiados
al almacén de versiones dejando las versiones
consumadas sin cambios.
En el ejemplo la recuperación se hará así:
Versiones Sombra
„
„
„
Las versiones tentativas, se denominan
versiones sombra. Cuando una transacción se
consuma se hace un nuevo mapa que
reemplaza al anterior.
Para restaurar los objetos el gestor de
recuperación lee el mapa y utiliza su
información para localizar los objetos en el
archivo de versiones.
El mapa debe estar siempre en un lugar bien
conocido: un archivo separado, al comienzo del
almacén de versiones.
27
Versiones Sombra
Mapa cuando T se consuma
Mapa al Inicio
A -> P1
B -> P2
C -> P0”
A -> P0
B -> P0´
C -> P0”
p0
100
P0´
200
P0”
300
p1
p2
80
p3
220
278
p4
242
28