Transacciones y Control de Concurrencia I

Procesamiento de
Transacciones
Material basado en los capítulos 12 y 13
del libro: Sistemas Distribuidos. CyD. G.
Coulouris, J. Dollimore and T. Kindberg.
Concurrencia
Commit
Aislamiento
Two phase commit
Bloqueos
Transacciones Planas
Roll Back
Atomicidad
Consistencia
Durabilidad
Transacciones Distribuidas
Gestor de Transacciones
Contenido

Definiciones Básicas
 Transacciones

Problemas del Control de Concurrencia
 Equivalencia
Secuencial
 Operaciones Conflictivas
 Problemas causados por el aborto de las
transacciones
Contenido

Mecanismos de Control de Concurrencia
 Control
de Concurrencia a través de bloqueos
 Control Optimista de la Concurrencia
 Ordenación por marcas de tiempo
Contenido

Transacciones Distribuidas
 Sistema
Manejador de Transacciones
 Transacciones Planas y Anidadas
 Commit y Abort en un Sistema Distribuido
 Control de Concurrencia
Por Bloqueo
 Optimista
 Marcas Temporales

Contenido

Recuperación de Transacciones
Exclusión mutua

Comunicación entre hilos

Java
 Wait: Un hilo llama a wait en un objeto para
suspenderse él mismo y permitir a otro hilo ejecutar
un método en ese objeto.
 Notify: Un hilo llama a notify en un objeto para
informar a cualquier hilo que esta esperando en el
objeto que ha cambiado alguno de sus datos.
- Uso eficiente de los recursos (CPU)
- Polítcasjustas que eviten starvation
Transacciones
Una transacción es una colección de acciones
que hacen transformaciones de los estados de
un sistema preservando la consistencia del
sistema
 Una transacción indica una operación atómica
exitosa, tal como por ejemplo la transferencia
de dinero de una cuenta a otra.
Trasferencia:
1) Débito, 2) Crédito
Ya sea una operación compuesta o no.

Definiciones

Consiste en una secuencia de operaciones que
se ejecuta en forma atómica (indivisible)
Todo o Nada
Aislamiento
Transacciones

Solicitudes atómicas:
 Aislamiento

Efectos intermedios no visibles
 Todo

o Nada
Todas las operaciones o ninguna  Atomicidad de
fallo, durabilidad. Objetos Recuperables
Propiedades ACID de las
Transacciones



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) efecto equivalente a una ejecución
secuencial.

Durabilidad (Durability) los efectos de una transacción
consumada no se pierden, perduran.
Implementación de las
Transacciones
El aislamiento se garantiza por protocolos
de control de concurrencia
 La atomicidad y durabilidad se garantizan
mediante protocolos de recuperación.

Modelo de fallo para
Transacciones
Lampson propuso un modelo de fallos para
transacciones distribuidas que considera los fallos
en: Discos, Servidores y Comunicación. En el
modelo se intenta que los algoritmos trabajen
correctamente en presencia de fallos predecibles,
pero no se hacen consideraciones cuando ocurre
un desastre. El modelo establece lo siguiente:
–
Las escrituras pueden fallar (no se escribe nada, o se
escribe un valor incorrecto). En este caso las lecturas
al disco pueden detectar (mediante una suma de
comprobación) cuando un bloque de datos es
incorrecto.
Modelo de fallo para
Transacciones
–
Los servidores pueden fallar ocasionalmente. Cuando
el servidor se reemplaza por otro, el nuevo proceso
debe realizar un proceso de recuperación utilizando
la memoria permanente y la información que le
puedan suministrar otros procesos. Las fallas
pueden ocurrir en cualquier instante de tiempo,
incluso durante un proceso de recuperación.
– Puede existir un retardo arbitrario antes de que llegue
un mensaje. Un mensaje se puede perder, duplicar o
modificar. Se pueden detectar mensajes modificados.
Los mensajes falsificados y corruptos que no se
puedan detectar se les considera como desastres.
C
C
C
TPS
Transaction
Manager
scheduler
Data Manager
Recovery
Manager
Cache
Manager
Estructura de un Sistema de
Manejo de Transacciones

En los servidores se puede
añadir manejo transaccional,
mediante un SMT. Este
Coordinador o manejador ,
provee operaciones para el
manejo de las transacciones.
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 y
todas las actualizaciones deben eliminarse.
Historia de vida de una
Transacción
Con éxito
AbreTransacción
Operación
Operación
Abortado por el cliente
Abortado por el servidor
AbreTransacción
Operación
Operación
AbreTransacción
Operación
Operación
El servidor aborta
la transacción
Operación
Operación
CierraTransacción
AbortaTransacción
ERROR en la operación
informado al cliente
Condiciones de Terminación


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.
Condiciones de Terminación
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.

Historia de vida de una
Transacción
•
Ruptura de un proceso:
–
Acciones en el servidor: (Falla en un
Servidor) se reemplaza, se abortan todas las
transacciones que no han finalizado, usa un
procedimiento de recuperación para obtener
los valores de transacciones consumadas.
(Falla en un Cliente): los servidores dan un
tiempo de expiración y abortan las
transacciones que no hayan finalizado en ese
tiempo.
Historia de vida de una
Transacción
•
Ruptura del proceso:
–
Acciones en el cliente: Si falla el servidor, al
cliente, después de un tiempo se le devolverá
un código de error. El cliente debe tener un
plan para reintentar la operación o abandonar
la tarea que estaba realizando.
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
Estructura de las Transacciones

Anidadas: las operaciones de una
transacción pueden ser transacciones
. Por ejemplo,
Begin_transaction Reservación
...
Begin_transaction Vuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
end {Hotel}
End_transaction Reservación
T: Transacción de Nivel Superior
Commit
subtransacción
T1:
T2:
Commit provisional
T11
Commit provisional
T12
Abort
T21
Commit provisional
Commit provisional
T211
Commit provisional
Transacciones anidadas
Subtransacción  Atómica
 Subtransacciones del mismo nivel 
concurrentes pero sus accesos a objetos
comunes son secuencializados.
 Pueden consumar o abortar
independientemente

http://sistemas-distribuidos.wikispaces.com/3.8.+Transacciones+distribuidas.
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:
 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 anidadas proporcionan un
nivel más alto de concurrencia entre
transacciones. Las transacciones de un mismo
nivel se pueden ejecutar en forma concurrente
pero sus accesos se deben secuencializar.
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.
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.
Transacciones Anidadas

Reglas para el commit de transacciones
anidadas (cont):
 Cuando
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
T: Transacción de Niver Superior
Commit
T1:
T2:
Commit provisional
T11
Commit provisional
T12
Abort
T21
Commit provisional
Commit provisional
T211
Commit provisional
Problemas de la Concurrencia
Las aplicaciones de BD manejan una gran
cantidad de datos “persistentes”, es decir
datos almacenados en dispositivos de
memoria secundaria.
 Un usuario típico de una BD, realiza
“queries” sobre los datos, como por
ejemplo: cuál es el saldo actual de mi
cuenta bancaria??

Necesidad de Concurrencia



En algunos sistemas no es crítico que los datos
estén actualizados al instante; dichas
actualizaciones pueden diferirse y hacerse en
batch. Este enfoque simplifica enormemente el
manejo de los datos.
Por ejemplo algunos Bancos a finales de los
noventa, hacían las actualizaciones en las
cuentas de los usuarios por la noche
La tendencia actual en los bancos es la de
mantener información actualizada al instante.
Necesidad de Concurrencia



En algunos sistemas las actualizaciones no
pueden diferirse: por ejemplo un sistema de
reserva de líneas aéreas o de compra de
entradas al teatro. Se necesita saber
inmediatamente si se ha podido reservar el
asiento.
En este tipo de aplicaciones pueden llegar
requerimientos simultáneos de muchos clientes:
Necesidad de concurrencia y de los problemas
que esto acarrea.
La concurrencia, permite también realizar
procesos más eficientes.
Propiedades ACID


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.
Actualizaciones perdidas
Problemas que trae la Concurrencia
Recuperaciones Inconsistentes
Solución: equivalencia secuencial
Problemas que trae el aborto de las transacciones
Lecturas sucias
Escrituras prematuras
Abortos en Cascada
Los protocolos tratarán de
evitar estos problemas
Los balances iniciales de A, B y C son 100$, 200$ y 300$

Actualizaciones Perdidas:
T:
balance = b.obtenBalance();
b.crédito(balance*1.1)
a.debito(balance/10)
U:
balance = b.obtenBalance();
b.crédito(balance*1.1)
c.debito(balance/10)
balance = b.obtenBalance(); 200$
balance = b.obtenBalance(); 200$
b.crédito(balance*1.1) 220$
b.crédito(balance*1.1) 220$
a.débito(balance/10) 80$
c.débito(balance/10) 280$
El valor final de B ha debido ser 242$, no 220$. U leyó un valor antes de que T
lo actualizara.

El problema viene por paralelizar, o
pretender que las 2 transacciones se
ejecuten concurrentemente cuando deben
ejecutarse en forma secuencial.
Los balances iniciales de A, B son de
200$

Recuperaciones Inconsistentes
V:
W:
Unasucursal.totalSucursal();
a.débito(100)
b.crédito(100)
/* El valor inicial de ambas cuentas es
200 */
a.débito(100)
$100
Total = a.obtenbalance();
total = total + b.balance(); // total=300
total = total + c.balance():
b.crédito(100)
$300
W vé el valor nuevo de a y el valor viejo de b. No se está cumpliendo la
propiedad de aislamiento.
Control de Concurrencia:
Solución al problema de actualizaciones
perdidas.
balance = b.obtenBalance(); 200$
b.Crédito(balance*1.1) 220$
a.Débito(balance/10)
balance = b.obtenBalance(); 220$
b.Crédito(balance*1.1) 242$
c.Débito(balance/10)
-Se puede conseguir serialización o algo equivalente (equivalencia
secuencial) secuenciando el acceso al objeto.
-La tabla es un ejemplo de secuenciación + cierto grado de concurrencia.
Serialización de Transacciones y Equivalencia
Secuencial
Operaciones conflictivas: 2 operaciones son conflictivas
cuando sus efectos combinados dependen del orden en el cual
fueron ejecutadas.
•
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.
•
Operaciones Conflictivas (no
conmutativas)
En el caso de un objeto bancario:
 Crédito y débito a una cuenta son
conmutativas? (el valor final es el mismo)
 crédito y crédito son conmutativas
 débito y débito son conmutativas
 read-balance y crédito no son conmutativas
 read-balance y débito no son conmutativas.
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 secuenciarse con respecto a su acceso
por otras transacciones.
Control de Concurrencia

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. Si las transacciones T y U acceden a
los objetos i y j en forma conflictiva, 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
T
U
A B
C
D
Todos los objetos sobre los cuales existan operaciones conflictivas tienen que ser accedidos por
las transacciones en el mismo orden.
i: T luego U
j: U luego T
Control de Concurrencia
Transacciones
A
B
C
A
B
C
Operaciones conflictivas
Delay
Ejecución
Operaciones compuestas
Serialización de operaciones
conflictivas
Control de Concurrencia
T
T: x=lee(i); escribe(i,10); escribe(j,20)
U: y=lee(j); escribe(j,30); z=lee(i)
U
x = lee(i)
escribe(i,10)
i: T luego U
j: U luego T
y = lee(j)
Escribe(j,30)
escribe(j,20)
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.
T lee i antes que U lo acceda, T no escribe j antes de que U la acceda
Control de concurrencia
Ejercicio 12.9 del libro:
 Un servidor gestiona los objetos a1, a2, … an. El
servidor proporciona dos operaciones a sus
clientes:
lee(i) devuelve el valor de ai
escribe (i, valor) asigna Valor a ai
Las transacciones T y U se definen de la siguiente
forma:
T: x=lee(j), escribe(j,44);
U: x=escribe(i,55); escribe (j,66);
Control de concurrencia
Un servidor gestiona los objetos a1, a2, … an. El
servidor proporciona dos operaciones a sus
clientes:
lee(i) devuelve el valor de ai
escribe (i, valor) asigna Valor a ai
Las transacciones T y U se definen de la siguiente
forma:
T: x=lee(j); y=lee(i); escribe(j,44); escribe (i,33);
U: x=lee(k); escribe(i,55); y=lee(j); escribe (k,66);

Proporcione tres solapamientos serialmente equivalentes de las transacciones T y U
Control de Concurrencia: Problemas que
generan las operaciones conflictivas

Recuperaciones Inconsistentes
V:
W:
Unasucursal.totalSucursal();
a.Débito(100)
b.Crédito(100)
/* El valor inicial de ambas cuentas es
200 */
a.Débito(100)
$100
Total = a.obtenbalance();
total = total + b.balance;
total = total + c.balance():
b.Crédito(100)
$300
V accede a «a» antes que W. V no accede a b antes de W.
a: V, W
b: W, V
Solución al 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():
Solución: Ejecución Secuencial
a: V,W
b: V, W
Actualizaciones perdidas
Problemas que trae la Concurrencia
Recuperaciones Inconsistentes
Problemas que trae el aborto de las transacciones
Lecturas sucias
Escrituras prematuras
Abortos en Cascada
Los protocolos trataran de
evitar estos problemas
Control de Concurrencia: Abortos,
más sobre la propiedad de
aislamiento.
No obstante pueden aparecer problemas aún en
presencia de ejecuciones secuencialmente
equivalentes. Esto es porque no hemos
considerado que una transacción puede abortar.
Se ha demostrado que la ejecución
secuencialmente equivalente es necesaria pero
no suficiente para la ejecución concurrente de
transacciones.
Control de Concurrencia
Las transacciones pueden abortar, ante esta situación
surgen otros problemas: lecturas sucias y escrituras prematuras
Lecturas Sucias
Transacción T
a.getBalance() (100$)
a.crédito(+10) (110$)
Transacción U
Lectura Sucia
a.getBalance() (110$)
a.crédito(+20) (130$)
commit
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

Una forma de evitar abortos en cascada
es permitir a las transacciones únicamente
leer objetos que fueron escritos por
transacciones consumadas. Es decir,
implementar de forma estricta la
propiedad de aislamiento.
Control de Concurrencia
Escrituras Prematuras
T:
a.crédito(+5)
a. Crédito(+5)
U:
b.crédito(+5)
a= 100$
105$
a.Crédito(+5)
a= 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 105$, pero se coloca
la imagen anterior a T que es 100$. La escritura de U es prematura, antes
de que T haga su commit.
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
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.
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.
Cuando una transacción se consuma, las VP se
llevan a almacenamiento permanente.
C
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.
Contenido

Mecanismos de Control de Concurrencia
 Control
de Concurrencia a través de bloqueos
 Control Optimista de la Concurrencia
 Ordenación por marcas de tiempo
 Comparación de métodos.
Control de Concurrencia: Bloqueos
balance = b.obtenBalance(); 200$
b.ponBalance(balance*1.1) 220$
a.Extrae(balance/10)
balance = b.obtenBalance(); 220$
b.ponBalance(balance*1.1) 242$
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 serializar es a través del uso de bloqueos exclusivos.
- El acceso a un objeto puede ser restringido mediante un lock. Sólo la transacción
que tenga el lock sobre el objeto podrá hacer operaciones sobre él.
Control de Concurrencia: Bloqueos
Exclusivos
T:
balance = b.obtenBalance();
b.ponBalance(balance*1.1)
a.Extrae(balance/10)
BeginTransaction
balance = b.obtenBalance(); Bloquea B
b.crédito(balance*1.1)
a.débito(balance/10)
Bloquea A
End Transaction Desbloquea A,B
U:
balance = b.obtenBalance();
b.ponBalance(balance*1.1)
c.Extrae(balance/10)
Begin Transaction
balance = b.obtenBalance(); Espera por B
Concedido B b.obtenBalance();
b.crédito(balance*1.1)
c.débito(balance/10) Bloquea C
End Transaction Desbloquea B,C
Control de Concurrencia:
Bloqueos
Cada vez que una transacción necesita leer o
escribir en un objeto, solicita un “lock” sobre
el mismo 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 el mismo sea
desbloqueado.
Control de Concurrencia:Bloqueos



Para lograr la 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 adquirir un nuevo bloqueo después
de que ha liberado alguno.
Existen dos fases:
 Adquirir
bloqueos (Fase de crecimiento)
 Liberar bloqueos (Fase de Acortamiento)
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
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.
Algoritmo de locking o bloqueo
Two Phase Locking
Fase de crecimiento
Strict Two Phase Locking
Fase de liberación
Fase de crecimiento
number of locks
number of locks
Time
Fase de liberación
Se liberan
todos los
locks
Time
Control de Concurrencia: Bloqueos
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 y
escritores: podemos tener muchos
lectores accediendo
concurrentemente a los datos.
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: ejm: tabla, registro, campo, etc.
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)
Algoritmo de locking o bloqueo
lock otorgado
Ninguno
•
•
lock solicitado
read -> OK - write -> OK
read
read -> OK - write -> Espera
write
read -> Espera - write -> Espera
Una mejora: utilizar locks de escritura y locks de lectura para
ofrecer mayor paralelismo al permitir que se realicen
concurrentemente transacciones que realizan operaciones no
conflictivas.
Los bloqueos de lectura se llaman también bloqueos
compartidos.
Bloqueos
•
Reglas de conflicto
–
–
Si una transacción T ha realizado una operación de
lectura en un objeto, entonces una transacción
concurrente U no debe escribir ese objeto hasta la
consumación de T, o que aborte.
Si una transacción T ha realizado una operación de
escritura en un objeto, entonces una transacción
concurrente U no debe leer o escribir ese objeto
hasta la consumación de T, o que aborte.
Bloqueos
Uso de bloqueos en un sistema de bloqueos de dos fases
estricto.
1.
Cuando una operación accede a un objeto en
una transacción:
a)
b)
c)
d)
2.
Si el objeto no estaba bloqueado, se bloquea y comienza la operación.
Si el objeto tiene activado un bloqueo conflictivo con otra transacción, la
transacción debe esperar hasta que esté desbloqueado.
Si el objeto tiene activado un bloqueo no conflictivo de otra transacción, se
comparte el bloqueo y comienza la operación.
Si el objeto ya ha sido bloqueado en la misma transacción, el bloqueo será
promovido si es necesario y comienza la operación. (Donde la promoción
está impedida por un bloqueo conflictivo, se utiliza la regla (b)).
Cuando una transacción se consuma o aborta, el
servidor desbloquea todos los objetos
bloqueados por la transacción.
Algoritmo de locking o bloqueo
Para asegurar que se sigan las reglas
de solicitud de locks 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.
Implementación de Bloqueos
•
•
•
La concesión de bloqueos será implementado
por un objeto separado del servidor que
llamaremos gestor de bloqueos.
El Gertor de Bloqueos mantiene en una
estructura de datos los locks concedidos.
Cada bloqueo es una instancia de la clase
Bloqueo que mantiene la siguiente información:
–
–
–
El identificador del objeto bloqueado.
Los identificadores de las transacciones que
mantienen actualmente el bloqueo
Un tipo de bloqueo.
Bloqueos
public class Bloqueo {
private Object objeto;
// El objeto que es protegido por el bloqueo
private Vector propietarios;
// las TID de los propietarios
private TipoBloqueo tipoBloqueo;
// el tipo actual
public synchronized void adquiere(IDTrans trans, TipoBloqueo unTipoBloqueo){
while(/* otra transacción posea el bloqueo en modo conflictivo */) {
try {
wait( );
}catch (InterruptedException e) {/*...*/ }
}
if (propietarios.estaVacio( )) { // ningún TID posee un bloqueo
propietarios.agregaElemento(trans);
tipoBloqueo = unTipoBloqueo;
} else if (/*otra transacción posee el bloqueo, lo comparte*/ ) ) {
if (/*esta transacción no es un poseedor*/) propietarios.agregaElemento(trans);
} else if (/* esta transacción es un poseedor pero necesita más de un bloqueo
exclusivo*/)
tipoBloqueo.promueve( );
}
}
Bloqueos
public synchronized void libera (IDTrans trans ){
holders.removeElement(trans); // elimina este poseedor
// establece el tipo de bloqueo a ninguno
notifyAll( );
}
}
Bloqueos
public class GestorBloqueo {
private Hashtable losBloqueos;
public void ponBloqueo(Object objeto, IDTrans trans, TipoBloqueo
tipoBloqueo){
Bloqueo bloqueoEncontrado;
synchronized (this){
// busca el bloqueo asociado con el objeto
// si no hay ninguno, lo crea y lo agrega a la tabla de dispersión
}
bloqueoEncontrado.agrega(trans, tipoBloqueo);
}
//sincroniza este dado que queremos eliminar todas las entradas
public synchronized void desBloqueo(TransID trans) {
Enumeration e = losBloqueos.elements( );
while(e.hasMoreElements( )){
Bloqueo unBloqueo = (Bloqueo)(e.nextElement());
if(/* trans is a holder of this lock*/ ) unBloqueo.libera(trans);
}
}
}
Bloqueo para Transacciones
Anidadas

El propósito 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 primera regla se logra disponiendo que
cada bloqueo que adquiere una
subtransacción es heredado por su padre
cuando esta finaliza (herencia del hijo al
Padre). Esto garantiza que puedan
mantenerse los bloqueos hasta que se
haya consumado o abortado la
transacción a nivel superior.
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.
Bloqueos (transacciones anidadas)
•
Reglas que describen la adquisición y
liberación del bloqueo:
–
Para que una subtransacción adquiera un
bloqueo de lectura sobre un objeto, ninguna
transacción activa puede tener un bloqueo de
escritura sobre ese objeto, y los únicos que
retienen un bloqueo de escritura son sus
ascendientes.
Bloqueos (transacciones anidadas)
–
–
–
Para que una subtransacción adquiera un bloqueo de
escritura sobre un objeto, ninguna otra transacción
activa puede tener un bloqueo de lectura o escritura
sobre ese objeto, y los únicos que retienen los
bloqueos de lectura y escritura en ese objeto son sus
ascendientes.
Cuando se consuma una transacción, sus bloqueos
son heredados por su padre, permitiendo al padre
retener los bloqueos del mismo modo que el hijo.
Cuando una subtransacción aborta, sus bloqueos son
eliminados. Si el padre todavía continúa manteniendo
los bloqueos puede continuar haciéndolo.
Las transacciones al mismo nivel que acceden a los mismos objetos realizan
turnos para adquirir los objetos retenidos por sus padres.
T: Transacción de Niver Superior
Commit
T1:
T2:
Commit provisional
T11
T12
Commit provisional
Abort
T21
Commit provisional
Commit provisional
T211
Commit provisional
Desean bloqueo
T: Transacción de Niver Superior
Commit
T1:
T2:
Commit provisional
T11
T12
Commit provisional
Abort
T21
Commit provisional
Commit provisional
T211
Commit provisional
Adquiere bloqueo que le pasa a T11 para su ejecución. T11
Lo devuelve cuando finaliza. Cuando T1 finaliza devuelve el bloqueo a T
Y es en ese momento cuando T2 lo puede adquirir.
Algoritmo de locking o bloqueo
El problema del algoritmo de bloqueo es que
puede ocasionar deadlocks o Interbloqueos.
T
a.Crédito()
U
bloqueo de escritura para A
b.Crédito() bloqueo de escritura para B
b.Débito
Espera por U
Bloqueo en B
a.Débito(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 (Hold and Wait).Los
procesos que tienen, en un momento dado, recursos asignados
con anterioridad, pueden solicitar nuevos recursos.
3.- Condición de no apropiación. Un proceso no puede ser
forzado a dejar los recursos otorgados con anterioridad. 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.
Poseído por
Espera por
R1
T
T
Espera por
R2
Poseído por
Grafo de Espera Circular: Si hay un ciclo en el grafo significa
que hay interbloqueo (deadlock).
Tratamiento de Interbloqueos
Políticas frente a los bloqueos:
1.- Detectar: dejar que suceda y luego recuperarse.
3.- Evitar que estructuralmente sea posible el deadlock,
es decir, asegurar que al menos una de las cuatro
condiciones no se cumpla. (EM, N Apropiació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).
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.
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.
Serialización de Transacciones a
través de locks.


El manejo de bloqueos (asignación, liberación)
causan un overhead adicional, lo mismo que
los algoritmos de prevención o detección
Disminuyen la concurrencia.
EJERCICIO
T
U
V
W
a.deposita(100)
b.deposita(100)
b.extrae(100)
c.extrae(100)
a.extrae(100)
c.deposita(100)
d.deposita(100)
b.deposita(100)
d.Deposita(100)
¿Bloqueo
indefinido?
Incrementando la concurrencia en
esquemas de bloqueo

Bloqueos de dos versiones



La activación de bloqueos exclusivos se retrasa hasta que
una T se
consuma
Bloqueos jerárquicos

Bloqueos de granularidad mixta
Incrementando la concurrencia en
esquemas de bloqueo

Bloqueos de dos versiones
•
Esquema optimista que permite que una transacción
escriba versiones tentativas.
• Las operaciones de lectura sólo esperan si otra
transacción se está consumando actualmente sobre
el mismo objeto.
• Tres tipos de bloqueo:
–
–
–
Bloqueo de lectura
Bloqueo de escritura
Bloqueo de consumación
Incrementando la concurrencia en
esquemas de bloqueo

Bloqueos de dos versiones
Para un objeto
Bloqueo que se establece
Lectura
Escritura
Consumación
Bien
Bien
Bien
Lectura
Bien
Bien
Espera
Escritura
Bien
Espera
Espera
Espera
Bloqueo ya establecido Ninguno
Consumación
Incrementando la concurrencia en
esquemas de bloqueo

Bloqueos Jerárquicos
•
En algunas aplicaciones la granularidad adecuada
para una operación no es apropiada para otra.
• Para reducir la sobrecarga, se permiten que
coexistan bloqueos de granularidad mezclados.
• Propuesta de Gray: La activación de un bloqueo
padre tiene el mismo efecto que la activación de
todos los bloqueos hijo equivalentes. Intención de
bloqueo
Incrementando la concurrencia en
esquemas de bloqueo

Bloqueos Jerárquicos
Sucursal
A
B
C
Cuenta
Semana
Lunes
Martes
Miércoles
Jueves
Viernes
Intervalos de tiempo
9:00–10:00
10:00–11:00 11:00–12:00 12:00–13:00 13:00–14:00 14:00–15:00 15:00–16:00
Incrementando la concurrencia en
esquemas de bloqueo

Bloqueos Jerárquicos
Para un objeto
Bloqueo ya activado
Bloqueo que se va a activar
Lectura
Escritura
I-Lectura
I-Escritura
Ninguno
Bien
Bien
Bien
Bien
Lectura
Bien
Espera
Bien
Espera
Escritura
Espera
Espera
Espera
Espera
I-Lectura
Bien
Espera
Bien
Bien
I- Escritura
Espera
Espera
Bien
Bien
Tabla de compatibilidad para bloqueos jerárquicos.