CAPITULO 6 Control de Concurrencia y Recuperación 6.1

ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
CAPITULO 6
Control de Concurrencia y Recuperación
6.1 Protocolos de Bloqueo
Un protocolo de bloqueo nace de la necesidad creada cuando una transacción solicita un bloqueo de un modo
particular sobre un elemento de datos y ninguna otra transacción posee un bloqueo sobre el mismo elemento de
datos en un modo conflictivo, se puede conceder el bloqueo. Sin embargo, hay que tener cuidado para evitar la
siguiente situación: suponemos que la transacción T2 posee un bloqueo en modo compartido sobre un
elemento de datos y que la transacción T1 solicita un bloqueo en modo exclusivo sobre dicho elemento de datos.
Obviamente T1 debe esperar a que T2 libere el bloqueo en modo compartido. Mientras tanto, la transacción T3
puede solicitar un bloqueo en modo compartido sobre el mismo elemento de datos. La petición de bloqueo es
compatible con el bloqueo que se ha concedido a T2, por tanto se puede conceder a T3 el bloqueo en
modo compartido. En este punto T2 puede liberar el bloqueo, pero T1 debe seguir esperando hasta que
T3 termine. Pero de nuevo puede haber una nueva transacción T4 que solicite un bloqueo en modo
compartido sobre el mismo elemento de datos y a la cual se conceda el bloqueo antes de que T3 lo libere. De
hecho es posible que haya una secuencia de transacciones que soliciten un bloqueo en modo compartido
sobre el elemento de datos, y que cada una de ellas libere el bloqueo un poco después de que sea concedido, de
forma que T1 nunca obtenga el bloqueo en modo exclusivo sobre el elemento de datos. La transacción T1 nunca
progresa y se dice que tiene inanición.
Se puede evitar la inanición de las transacciones al conceder los bloqueos de la siguiente manera: cuando una
transacción Ti solicita un bloqueo sobre un elemento de datos Q en un modo particular M, el gestor de control
de concurrencia concede el bloqueo siempre que:
1
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
 No exista otra transacción que posea un bloqueo sobre Q en un modo que esté en conflicto con M.

No exista otra transacción que esté esperando un bloqueo sobre Q y que lo
haya solicitado antes que Ti.
De este modo, una petición de bloqueo nunca se quedará bloqueada por otra petición de bloqueo solicitada más
tarde.
Existen diferentes protocolos de bloqueo que se pueden utilizar en entornos distribuidos, entre los que se
encuentran el protocolo de bloqueo de dos fases, protocolos basados en grafos, entre otros. La única
modificación que hay que incorporar es el modo en que el gestor de bloqueos trata los datos replicados. Se
presentan varios esquemas posibles que son aplicables a entornos en que los datos puedan replicarse en varios
sitios. Esta situación se presenta en los modos de bloqueo compartido y exclusivo.
En el enfoque de gestor único de bloqueos el sistema mantiene un único gestor de bloqueos que reside en un sitio
único escogido. Todas las solicitudes de bloqueo y de desbloqueo se realizan en el sitio. Cuando una transacción
necesita bloquear un elemento de datos envía una solicitud de bloqueo al sitio. El gestor de bloqueos determina si
se puede conceder el bloqueo de manera inmediata. Si se puede conceder el bloqueo, el gestor de bloqueos
envía un mensaje con ese objeto al sitio en el que se inició la solicitud de bloqueo. En caso contrario, la
solicitud se retrasa hasta que puede concederse, en cuyo momento se envía un mensaje al sitio en el que se
inició la solicitud de bloqueo. La transacción puede leer el elemento de datos de cualquiera de los sitios en
los que residen las réplicas del elemento de datos. En caso de una operación de escritura deben implicarse en la
2
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
escritura todos los sitios en los que residen réplicas del elemento de datos.
El esquema tiene las siguientes ventajas:
Implementación sencilla. Este esquema necesita dos mensajes para tratar
sólo uno para las de desbloqueo.
las solicitudes de bloqueo y
Tratamiento sencillo de los interbloqueos. Dado que todas las solicitudes de
bloqueo y de desbloqueo
se realizan en un solo sitio, se pueden aplicar
directamente a este entorno algoritmos de tratamiento
de los interbloqueos.
Los inconvenientes del esquema son:
Cuello de botella. El sitio se transforma en un cuello de botella, dado que
procesarse allí.
todas las solicitudes deben
Vulnerabilidad. Si el sitio falla se pierde el controlador de la concurrencia.
Se
debe
detener
el
procesamiento o utilizar un esquema de recuperación
de modo que pueda asumir la administración de
los bloqueos un sitio de respaldo.
6.2 Marcas Temporales
Otro método para determinar el orden de secuencialidad en la ejecución de bloqueo de datos es seleccionar
previamente un orden entre las transacciones en el método más común para hacer esto es utilizar un esquema de
ordenación por marcas temporales
3
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
El protocolo de ordenación por marcas temporales asegura que todas las operaciones leer y escribir
conflictivas se ejecutan en el orden de las marcas temporales.
El protocolo de ordenación por marcas temporales asegura la secuencialidad en cuanto a conflictos. Esta
afirmación se deduce del hecho de que las operaciones conflictivas se procesan durante la ordenación de las
marcas temporales. El protocolo asegura la ausencia de interbloqueos, ya que ninguna transacción tiene que
esperar. El protocolo puede generar planificaciones no recuperables; sin embargo se puede extender para
producir planificaciones sin cascada.
Otro esquema utilizado es el mecanismo de marcas de tiempo, este supone que existe una única versión de los
datos; por lo que sólo una transacción puede acceder a los mismos. Se puede relajar esta restricción
permitiendo que varias transacciones lean y escriban diferentes versiones del mismo dato siempre que cada
transacción vea un conjunto consistente de versiones de todos los datos a los que accede.
El problema con las técnicas de bloqueo es que puede producirse un interbloqueo (llamado deadlock), que es
una situación que se da cuando dos o más transacciones están esperando cada una de ellas que otra
libere algún objeto antes de seguir. Este problema, que ha sido estudiado en profundidad en los sistemas
operativos, puede tener dos soluciones:
 Prevenir el interbloqueo, obligando a que las transacciones bloqueen todos
adelantado.
los elementos que necesitan por
 Detectar el interbloqueo, controlando de forma periódica si se ha producido, para lo que suele construirse un
grafo de espera. Si existe un ciclo en el grafo se tiene un interbloqueo. Cada SGBD tiene su propia política
para escoger las transacciones bloqueadas, aunque suelen ser las transacciones más recientes.
6.3 Tratamiento de los Interbloqueos
4
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
Un sistema está en estado de interbloqueo si existe un conjunto de transacciones tal que toda transacción del
conjunto está esperando a otra transacción del conjunto. En tal situación ninguna de las transacciones puede
progresar.
El único remedio a esta situación no deseada es que el sistema invoque alguna acción drástica, como retroceder
alguna de las transacciones involucradas en el interbloqueo. El retroceso de una transacción puede ser parcial:
esto es, se puede retroceder una transacción hasta el punto donde obtuvo un bloqueo cuya liberación
resuelve el interbloqueo.
Existen dos métodos principales para tratar el problema de los interbloqueos. Se puede utilizar un protocolo de
prevención de interbloqueos para asegurar que el sistema nunca llega a un estado de interbloqueo. De forma
alternativa se puede permitir que el sistema llegue a un estado de interbloqueo, y tratar de recuperarse después a
través de un esquema de detección y recuperación de interbloqueos.
Estos algoritmos de prevención y de detección de interbloqueos pueden utilizarse en los sistemas distribuidos,
siempre que se realicen modificaciones. Por ejemplo, se puede utilizar el enfoque de ordenación por marcas
temporales puede aplicarse de manera directa en entornos distribuidos.
La prevención de interbloqueos puede dar lugar a esperas y retrocesos innecesarios. Además,
puede que algunas técnicas de prevención de interbloqueos necesiten que se impliquen en la ejecución de
una transacción más sitios que los que serían necesarios de otro modo.
6.4 Disponibilidad
Para garantizar que una aplicación distribuida sea altamente disponible (es decir, que pueda estar en servicio de
manera continua) se deben instanciar múltiples réplicas de esta en distintos equipos de cómputo. Según el
tipo de fallo que se quiera soportar (cortes de energía eléctrica, averías, desconexiones) se debe conseguir
que cada uno de las computadoras que mantenga una réplica de la BDD sea independiente del resto ante
5
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
la ocurrencia de tales fallos. Así, por ejemplo, si queremos proteger a la aplicación ante cortes de
alimentación, cada equipo de computo donde se ejecute una réplica debería disponer de su propio sistema de
protección, por ejemplo una UPS de alto rendimiento.
El hecho de disponer de múltiples replicas permitirá que la capacidad de servicio de la aplicación también
mejore. Así, aquellas peticiones de los usuarios del sistema que sólo impliquen una consulta de datos,
podrán ser atendidas por diferentes replicas simultáneamente. Con ello, el tiempo de respuesta percibido por los
usuarios disminuirá.
Por tanto, con la replicación se pueden llegar a obtener dos mejoras importantes:
 Por un lado, se garantiza que el servicio ofrecido por la aplicación, no se vea interrumpido en caso de que
se dé un fallo en alguna de las réplicas.
Observemos que tal fallo habría dejado inutilizable a la aplicación en caso de no haber empleado replicación.
Además, el tiempo necesario para restablecer el servicio en la aplicación podría llegar a ser grande en algunos
tipos de fallo. Por ejemplo, si se llegara a estropear el disco duro en el que se mantienen parte de los datos de
la aplicación: habría que parar la máquina, sustituir el disco, restaurar su contenido a partir de alguna copia de
seguridad, re arrancar la máquina y reiniciar la aplicación. Además, todas las peticiones en curso en el
momento de fallo se habrían perdido. Afortunadamente, un RAID evitaría esta situación.
 Por otra parte, la capacidad de servicio se ve incrementada cuando las peticiones
clientes únicamente implican consultas.
efectuadas
por
los
6.5 Replica con Grado de Consistencia Bajo
En general, el sistema de réplica de la BDD hace que las consultas sean más eficientes, pero complica las
6
ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
Bases de Datos Distribuidas
actualizaciones debido al problema de la redundancia de datos y el mantenimiento de la consistencia de los
datos. Normalmente, se elige una de las réplicas como copia principal para simplificar la administración, esta
situación garantiza que no exista el problema de que exista la réplica con un grado de consistencia bajo, que sería
una réplica que se generó con pérdida de información.
Si queremos garantizar una consistencia fuerte entre las réplicas habría que solicitar una entrega en orden
total. Es decir, todos los mensajes deben entregarse en idéntico orden en todos los procesos del grupo. No
obstante, ciertos tipos de aplicación sólo requieren el uso de orden causal (esto es, bastarla con ordenar
aquellos mensajes con relación “causa-efecto” entre ellos) que permite una entrega más rápida.
7