Transparencia de control de concurrencia distribuido

TRANSPARENCIA DE LA CONCURRENCIA

En un DBMS centralizado, esto significa que todas las transacciones que se ejecuten concurrentemente deben ejecutarse independientemente y deben estar consistentes con los resultados que se obtuvieran silas transacciones se ejecutaran una a un tiempo, en cualquier orden arbitrario. Sin embargo, el DDBMS debe asegurar la consistencia de todas las substracciones de una transacción global.

El control de concurrencia distribuido es muy importante en los ambientes de base de datos distribuidos porque las operaciones entre múltiples sitios y múltiples procesos tienen a generar inconsistencias en los datos y problemas de abrazos mortales (deadlocks) en las transacciones mas que en los ambientes de un solo sistema . Pos ejemplo, un procesador de transacciones TP Componente de un DDBMS debe asegurarse que todas las partes de la transacción en todos los sitios, se terminen satisfactoria mente antes que el COMMIT final se ejecute para comprometer la transacción. Suponga que cada operación de la transacción se compromete por cada procesador de datos DP local pero uno no puede comprometer los resultados de la transacción . Este escenario generaría un estado inconsistente. La solución a este problema se da con el Protocolo de Compromiso de dos fases.

Protocolo Commit de dos fases

Transparencia a Fallas

En una DBMS centralizado este debe proporcionar un mecanismo de recuperación que asegure que en caso de fallas,las transacciones deben ser atómicas y durables (ACID properties). Sin embargo en un DDBMS, este debe de poder recuperarse en caso de fallas como perdidas de mensajes, fallas en ligas de comunicación , falla de un sitio , particionado de red, etc . Y asegurar la atomicidad y durabilidad de transacciones globales.

Las bases de datos centralizadas requieren solamente un procesador de datos (DP), todas las operaciones de base dedatos se realizan en un solo sitio , y los resultados de las operaciones en la base de datos se realizan en un solo sitio, y los resultados de las operaciones en la base de datos son conocidas de inmediato por el DBMS .

En contraste , las base de datos distribuidas hacen posible esto a tráves de que la transacción acceso a los datos en diversos sitios, un COMMIT final no debe darse hasta que todos los sitios han comprometido sus partes de la transacción.

El protocolo de dos fases garantiza que si una porción de una operación de la transacción no pudo ser comprometida, todos los cambios realizados en los otros sitios participantes en la transacción serán deshechos para mantener la consistencia en el estado de la base de datos.

Cada procesador de datos tiene su propia bitácora de transacciones (transactions log). El protocolo de dos fases

requiere registrar una entrada en cada bitácora de transacciones de su procesador de datos (DP) antes de que el fragmente sea realmente actualizado. Por tanto, el protocolo requiere usar el protocolo (hacer-deshacer y rehacer) DO-UNDO-REDO y el protocolo (escritura anticipada) write-ahead.

Protocolo DO-UNDO-REDO

a)Do ejecuta la correspondiente operación y registra sus valores antes y después de la operación (before and after image) en la bitácora de transacciones.

b) UNDO deshace la operación aplicando los valores anteriores guardados en la bitácora de transacciones por la fase DO

c) REDO deshace la operación aplicando los valores posteriores guardados en la bitácora de transacciones por la fase DO.

Para asegurar que las operaciones (hacer- deshacer y rehacer) puedan recuperar de una falla en el sistema cuando requieran ejecutarse, se usa el protocolo write-ahead. Este protocolo forza que las entradas en el log de transacciones se guarden en disco antes que la operación tome lugar

Protocolo COMMITS

(dos fases)

El protocolo commits de dos fases define las operaciones entre dos tipos de nodo, el coordinador y uno o mas subordinados o conjuntos. El protocolo es implementados en dos fases:

Fase de Preparación

El coordinador manda un mensaje PREPARE COMMIT a todos los subordinados.

Los subordinados reciben el mensaje , escriben en su bitácora de transacciones, usando el protocolo Write-ahead y mandan un mensaje de confirmación (acknowledge) YES o PREPARED TO COMMIT) o (NO o NOT PREPARED ) al coordinador.

El coordinador se asegura que todos los nodos estén listos para comprometer la trasacción (commit) o este abortara la transacción .Si todos los nodos están preparados para comprometer su parte de la transacción se iniciara la fase 2 . Si uno o mas nodos no están preparados el coordinador mandara un mensaje a todos (BROADCAST) los subordinados de ABORT.

COMMIT FINAL

El coordinador anda mensaje a todos (BROADCAST) los subordinados de COMMIT y espera por las respuestas Cada Subordinado recibe el mensaje COMMIT y procede a actualizar la base de datos usando el protocolo DO (hacer) Los subordinados responden con un mensaje COMMITED o un NOT COMMITED al cordinador.

Si uno o mas subordinados no comprometen su parte de la transacción , el coordinador manda mensaje de ABORT , forzándolos a UNDO (deshacer) los cambios.

El objetivo del commit de dos fases es asegurarse que todos los nodos comprometieron su parte de la transacción o la transacción se aborta.

Conclusiones: las base de datos centralizadas que se ejecuten con las transacciones y que por el protocolo de coomits idenpendiente deben estar consistentes con el commit final y el de 2 fases.