A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.

Fase de confirmación

Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.

Los procesos concurrentes pueden ser ejecutados realmente de forma simultánea, sólo cuando cada uno es ejecutado en diferentes procesadores. En cambio, la concurrencia es simulada si sólo existe un procesador encargado de ejecutar todos  los procesos, simulando la concurrencia, ocupándose de forma alternada de uno y otro proceso a muy pequeños intervalos de tiempo. De esta manera simula que se están ejecutando a la vez.

Algunos casos de concurrencia, pueden ser:

• La multiprogramación, ya que el tiempo del procesador es compartido dinámicamente por varios procesos.
• Las aplicaciones estructuradas, donde la programación estructurada se implementa como un conjunto de procesos concurrentes.
• También se tiene que la misma estructura recién mencionada es utilizada en el diseño de los sistemas operativos, los cuales se implementan como un conjunto de procesos.Debido a que los procesos concurrentes en un sistema pueden interactuar entre otros también en ejecución, el número de caminos de ejecución puede ser extremadamente grande, resultando en un comportamiento sumamente complejo. Las dificultades asociadas a la concurrencia han sido pensadas para el desarrollo de lenguajes de programación y conceptos que permitan hacer la concurrencia más manejable.

TRANSACCIONES

Los sistemas que tratan el problema de control de concurrencia permiten que sus usuarios asuman que cada una de sus aplicaciones se ejecuta atómicamente, como si no existieran otras aplicaciones ejecutándose concurrentemente. Esta abstracción de una ejecución atómica y confiable de una aplicación se conoce como una transacción.

Un algoritmo de control de concurrencia asegura que las transacciones se ejecuten atómicamente controlando la intercalación de transacciones concurrentes, para dar la ilusión de que las transacciones se ejecutan serialmente, una después de la otra, sin ninguna intercalación. Las ejecuciones intercaladas cuyos efectos son los mismos que las ejecuciones seriales son denominadas serializables y son correctos ya que soportan la ilusión de la atomicidad de las transacciones.

El concepto principal es el de transacción. Informalmente, una transacción es la ejecución de ciertas instrucciones que acceden a una base de datos compartida. El objetivo del control de concurrencia y recuperación es asegurar que dichas transacciones se ejecuten atómicamente, es decir:

Cada transacción accede a información compartida sin interferir con otras transacciones, y si una transacción termina normalmente, todos sus efectos son permanentes, en caso contrario no tiene afecto alguno.

Una base de datos está en un estado consistente si obedece todas las restricciones de integridad (significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondientes debe existir) definidas sobre ella.

Los cambios de estado ocurren debido a actualizaciones, inserciones y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entre en un estado de inconsistencia.

PROPIEDADES FUNDAMENTALES DE UNA TRANSACCIÓN

•  Atomicidad: Se refiere al hecho de que una transacción se trata como una unidad de operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales sean anulados.

•  Consistencia: La consistencia de una transacción es simplemente su correctitud. En otras palabras, una transacción es un programa correcto que lleva a la base de datos de un estado consistente a otro con la misma característica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos.

•  Aislamiento: Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial.

•  Permanencia: Es la propiedad de las transacciones que asegura que una vez que una transacción finaliza exitosamente, sus resultados son permanentes y no pueden ser borrados de la base de datos por alguna falla posterior.

PROBLEMAS DE CONCURRENCIA

Existen tres formas en las que una transacción, aunque sea correcta por sí misma, puede producir una respuesta incorrecta si alguna otra transacción interfiere con ella en alguna forma.

Consideremos que la transacción que interfiere también puede ser correcta; lo que produce el resultado incorrecto general es el intercalado sin control entre las operaciones de las dos transacciones correctas.

Los tres problemas son:

• El problema de la Actualización Perdida
• El problema de la Dependencia No Confirmada
• Sl problema del Análisis Inconsistente

CONTROL DE CONCURRENCIA EN BASES DE DATOS

En los ejemplos anteriores, los errores fueron causados por la ejecución intercalada de operaciones de transacciones diferentes. Los ejemplos no muestran todas las posibles formas en las que la ejecución de dos transacciones pueden interferir, pero sí ilustran dos de los problemas que surgen con frecuencia debido a la intercalación. Para evitar estos problemas, se deben controlar las intercalaciones entre transacciones.

El control de transacciones concurrentes en una base de datos brinda un eficiente desempeño del Sistema de Administración de Base de Datos, puesto que permite controlar la ejecución de transacciones que operan en paralelo, accediendo a información compartida y, por lo tanto, interfiriendo potencialmente unas con otras.

El objetivo de los métodos de control de concurrencia es garantizar la no inferencia o la propiedad de aislamiento de transacciones que se ejecutan de manera concurrente. Los distintos objetivos atacan el problema garantizando que las transacciones se ejecuten en un plan que sea serializable, es decir, que el resultado sea equivalente a el resultante de ejecutar un plan en serie.

El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (bloqueos) y aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones.

Los algoritmos pesimistas sincronizan la ejecución concurrente de las transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la sincronización de las transacciones hasta su terminación. Ambos grupos de métodos, pesimistas y optimistas, consisten de algoritmos basados en bloqueos y algoritmos basados en marcas de tiempo, entre otros.

Los protocolos basados en bloqueos son los más utilizados por los DBMS comerciales. Los demás tienen un alcance más teórico que práctico.

NUEVOS PROBLEMAS (que no se dan en SGBD Centralizados)

_ Designar una COPIA DISTINGUIDA:

solicitudes de bloqueo y desbloqueo se envían al sitio que contiene la copia distinguida (coordinador)

_ Sitio primario

_ Sitio primario con sitio de respaldo

_ Copia primaria

SOLUCIÓN

: Extensión de las técnicas utilizadas en BD centralizadas

_ TÉCNICAS DE BLOQUEO:

_ Designar una COPIA DISTINGUIDA:

solicitudes de bloqueo y desbloqueo se envían al sitio que contiene la copia distinguida (coordinador)

_ Sitio primario

_ Sitio primario con sitio de respaldo

_ Copia primaria

_ MÉTODO DE VOTACIÓN

COPIA DISTINGUIDA (I)

_ Sitio primario

_ Un único sitio como coordinador para todos los elementos de la base de datos

_ VENTAJAS:

_ Simple extensión del enfoque centralizado

_ DESVENTAJAS:

_ Todas las solicitudes de bloqueo se envían a un mismo sitio (sobrecarga y cuello de botella)

_ Fallo del sitio primario paraliza el sistema

Sitio primario con sitio de respaldo

_ Se designa un sitio de respaldo por si ocurre fallo en sitio primario

_ Información de bloqueo se mantiene tanto en sitio primario como en sitio de respaldo

_ VENTAJAS:

_ Simplicidad, basta con elegir un nuevo sitio de respaldo

_ DESVENTAJAS:

_ El proceso de adquisición de bloqueos se hace más lento

_ Sobrecarga del sitio primario y de respaldo

Copia primaria

_ Copias distinguidas de diferentes elementos de información almacenadas en diferentes sitios

_ VENTAJA:

_ Fallo en un sitio sólo afecta a transacciones con bloqueos concedidos en dicho sitio. El resto de las transacciones no resultan afectadas

MÉTODO DE VOTACIÓN

_ Solicitudes de bloqueo se envían a todos los sitios con copia del elemento de información (no hay copia distinguida)

_ Cada copia puede conceder o rechazar la solicitud

_ Transacción obtiene bloqueo si mayoría de las copias lo conceden

_ Si no recibe mayoría de votos de concesión en un tiempo, cancelará su solicitud

_ Mayor complejidad por el número de mensajes y los tratamientos de fallo

BLOQUEOS

Un bloqueo en general es cuando una acción que debe ser realizada está esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevención, detección, y recuperación. También es necesario considerar factores como que hay sistemas en los que permitir un bloqueo es inaceptable y catastrófico, y sistemas en los que la detección del bloqueo es demasiado costosa.

En el caso específico de las bases de datos distribuidas usar bloqueo de recursos, peticiones para probar, establecer o liberar bloqueos requiere mensajes entre los manejadores de transacciones y el calendarizador. Para esto existen dos formas básicas:

• Autónoma: cada nodo es responsable por sus propios bloqueos de recursos.
  • Una transacción sobre un elemento con n replicas requiere 5n mensajes
  • Petición del recurso
  • Aprobación de la petición
  • Mensaje de la transacción
  • Reconocimientos de transacción exitosa
  • Peticiones de liberación de recursos
• Copia Primaria: un nodo primario es responsable para todos los bloqueos de recursos
  • Una transacción sobre un elemento con n copias requiere n mensajes
  • Una petición del recurso
  • Una aprobación de la petición
  • n mensajes de la transacción
  • n reconocimientos de transacción exitosa
  • Una petición de liberación de recurso

Podemos definir que dos operaciones entran en conflicto que debe ser resuelto si ambas acceden a la misma data, y una de ellas es de escritura y si fueron realizadas por transacciones distintas.

Bloqueo Mortal

En sistemas operativos, el bloqueo mutuo (también conocido como interbloqueo, traba mortal, deadlock, abrazo mortal) es el bloqueo permanente de un conjunto de procesos o hilos de ejecución en un sistema concurrente que compiten por recursos del sistema o bien se comunican entre ellos. A diferencia de otros problemas de concurrencia de procesos, no existe una solución general para los interbloqueos.

Todos los interbloqueos surgen de necesidades que no pueden ser satisfechas, por parte de dos o más procesos. En la vida real, un ejemplo puede ser el de dos niños que intentan jugar al arco y flecha, uno toma el arco, el otro la flecha. Ninguno puede jugar hasta que alguno libere lo que tomó.

En el siguiente ejemplo, dos procesos compiten por dos recursos que necesitan para funcionar, que sólo pueden ser utilizados por un proceso a la vez. El primer proceso obtiene el permiso de utilizar uno de los recursos (adquiere el lock sobre ese recurso). El segundo proceso toma el lock del otro recurso, y luego intenta utilizar el recurso ya utilizado por el primer proceso, por lo tanto queda en espera. Cuando el primer proceso a su vez intenta utilizar el otro recurso, se produce un interbloqueo, donde los dos procesos esperan la liberación del recurso que utiliza el otro proceso.

SERIABILIDAD

Una forma de evitar los problemas de interferencia es no permitir que las transacciones se intercalen. Una ejecución en la cual ninguna de dos transacción se intercala se conoce como serial. Para ser más precisos, una ejecución se dice que es serial si, para todo par de transacciones, todas las operaciones de una transacción se ejecutan antes de cualquier operación de la otra transacción. Desde el punto de vista del usuario, en una ejecución serial se ve como si las transacciones fueran operaciones que el DBS procesa atómicamente. Las transacciones seriales son correctas dado que cada transacción es correcta individualmente, y las transacciones que se ejecutan serialmente no pueden interferir con otra.