CAPITULO 6. Control de Concurrencia y Recuperación

Transcripción

1 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

2 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

3 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

4 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

5 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

6 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 efectuadas por los clientes únicamente implican consultas. 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

7 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