Bloqueo en dos fases

Bloqueo en dos fasesEditar

Según el protocolo de bloqueo en dos fases, una transacción maneja sus bloqueos en dos fases distintas y consecutivas durante la ejecución de la transacción:

1. Fase de expansión (aka fase de crecimiento): se adquieren bloqueos y no se liberan (el número de bloqueos sólo puede aumentar).
2. Fase de contracción (también conocida como fase de contracción): se liberan los bloqueos y no se adquieren bloqueos.

Las reglas de bloqueo de las dos fases pueden resumirse como: nunca se adquiere un bloqueo después de que se haya liberado otro. La propiedad de serializabilidad está garantizada para un cronograma con transacciones que obedecen esta regla.

Típicamente, sin conocimiento explícito en una transacción sobre el final de la fase 1, se determina con seguridad sólo cuando una transacción ha completado el procesamiento y solicitado el commit. En este caso, todos los bloqueos pueden ser liberados a la vez (fase 2).

Conservar el bloqueo bifásicoEditar

La diferencia entre 2PL y C2PL es que las transacciones de C2PL obtienen todos los bloqueos que necesitan antes de que las transacciones comiencen. Esto es para asegurar que una transacción que ya tiene algunos bloqueos no se bloquee esperando otros bloqueos. La 2PL conservadora evita los deadlocks.

Bloqueo bifásico estrictoEditar

Para cumplir con el protocolo S2PL, una transacción necesita cumplir con la 2PL, y liberar sus bloqueos de escritura (exclusivos) sólo después de que haya terminado, es decir, de que se haya comprometido o abortado. Por otro lado, los bloqueos de lectura (compartidos) se liberan regularmente durante la fase 2. Este protocolo no es apropiado en B-trees porque provoca un cuello de botella (mientras que los B-trees siempre empiezan a buscar desde la raíz padre).

Bloqueo bifásico estricto fuerteEditar

o Rigurosidad, o Programación rigurosa, o Bloqueo bifásico riguroso

Para cumplir con el bloqueo bifásico estricto fuerte (SS2PL) el protocolo de bloqueo libera tanto los bloqueos de escritura (exclusivos) como los de lectura (compartidos) aplicados por una transacción sólo después de que ésta haya terminado, es decir, sólo después de que se haya completado la ejecución (esté lista) y se haya comprometido o abortado. Este protocolo también cumple con las reglas S2PL. Una transacción que obedece a SS2PL puede ser vista como si tuviera una fase 1 que dura toda la ejecución de la transacción, y ninguna fase 2 (o una fase 2 degenerada). Por lo tanto, sólo queda una fase en realidad, y «bifásico» en el nombre parece seguir utilizándose debido al desarrollo histórico del concepto a partir de 2PL, y siendo 2PL una superclase. La propiedad SS2PL de un horario también se llama Rigor. También es el nombre de la clase de horarios que tienen esta propiedad, y un horario SS2PL también se llama «horario riguroso». El término «Rigurosidad» está libre del legado innecesario de «bifásico», además de ser independiente de cualquier mecanismo (de bloqueo) (en principio se pueden utilizar otros mecanismos de bloqueo). El mecanismo de bloqueo respectivo de la propiedad se denomina a veces Rigorous 2PL.

SS2PL es un caso especial de S2PL, es decir, la clase de cronogramas SS2PL es una subclase propia de S2PL (todo cronograma SS2PL es también un cronograma S2PL, pero existen cronogramas S2PL que no son SS2PL).

SS2PL ha sido el protocolo de control de concurrencia elegido por la mayoría de los sistemas de bases de datos y utilizado desde sus inicios en la década de 1970. Ha demostrado ser un mecanismo eficaz en muchas situaciones, y proporciona además de Serializability también Strictness (un caso especial de Cascadeless Recoverability), que es instrumental para la recuperación eficiente de la base de datos, y también Commitment ordering (CO) para participar en entornos distribuidos donde se emplean soluciones de serializability distribuida y serializability global basadas en CO. Al ser un subconjunto de CO, existe una implementación eficiente de SS2PL distribuido sin un gestor de bloqueos distribuido (DLM), mientras que los bloqueos distribuidos (véase más adelante) se resuelven automáticamente. El hecho de que SS2PL empleado en sistemas de bases de datos múltiples asegura la serializabilidad global ha sido conocido durante años antes del descubrimiento de CO, pero sólo con CO vino la comprensión del papel de un protocolo de compromiso atómico en el mantenimiento de la serializabilidad global, así como la observación de la resolución automática de bloqueos distribuidos (ver un ejemplo detallado de SS2PL distribuido). De hecho, el hecho de que SS2PL herede las propiedades de Recoverability y CO es más significativo que ser un subconjunto de 2PL, que por sí mismo en su forma general, además de comprender un simple mecanismo de serializabilidad (sin embargo, la serializabilidad también está implícita en CO), no se sabe que proporcione a SS2PL ninguna otra cualidad significativa. La 2PL en su forma general, así como cuando se combina con el rigor, es decir, la 2PL estricta (S2PL), no se conoce que se utilice en la práctica. La popular SS2PL no requiere marcar el «final de la fase 1» como hacen la 2PL y la S2PL, por lo que es más sencilla de implementar. Además, a diferencia del 2PL general, el SS2PL proporciona, como se mencionó anteriormente, las útiles propiedades de ordenación Strictness y Commitment.

Existen muchas variantes de SS2PL que utilizan varios tipos de bloqueo con varias semánticas en diferentes situaciones, incluyendo casos de cambio de tipo de bloqueo durante una transacción. Son notables las variantes que utilizan el bloqueo de granularidad múltiple.

1. SS2PL vs. S2PL: Ambos proporcionan serializabilidad y rigurosidad. Dado que S2PL es una superclase de SS2PL puede, en principio, proporcionar más concurrencia. Sin embargo, no se nota ninguna ventaja de concurrencia en la práctica (existe exactamente el mismo bloqueo para ambos, con una liberación de bloqueos prácticamente no mucho más temprana para S2PL), y la sobrecarga de tratar con un mecanismo de fin de fase-1 en S2PL, separado del fin de la transacción, no se justifica. Además, mientras que SS2PL proporciona el ordenamiento de los compromisos, S2PL no lo hace. Esto explica la preferencia de SS2PL sobre S2PL.
2. Especialmente antes de 1990, pero también después, en muchos artículos y libros, por ejemplo, (Bernstein et al. 1987, p. 59), el término «Strict 2PL» (S2PL) ha sido frecuentemente definido por el protocolo de bloqueo «Release all locks only after transaction end», que es el protocolo de SS2PL. Así, «Strict 2PL» no podría ser allí el nombre de la intersección de Strictness y 2PL, que es mayor que la clase generada por el protocolo SS2PL. Esto ha causado confusión. Con una definición explícita de S2PL como la intersección de Strictness y 2PL, un nuevo nombre para SS2PL, y una distinción explícita entre las clases S2PL y SS2PL, los artículos (Breitbart et al. 1991) y (Raz 1992) han pretendido despejar la confusión: el primero utilizando el nombre «rigorismo», y el segundo «SS2PL.»
3. Existe una propiedad más general que SS2PL (una superclase de programación), el ordenamiento de compromiso estricto (Strict CO, o SCO), que también proporciona tanto serializabilidad, rigurosidad y CO, y tiene una sobrecarga de bloqueo similar. A diferencia de SS2PL, SCO no bloquea en caso de conflicto de lectura-escritura (un bloqueo de lectura no bloquea la adquisición de un bloqueo de escritura; tanto SCO como SS2PL tienen el mismo comportamiento para los conflictos de escritura-lectura y escritura-escritura) a costa de un posible retraso en la confirmación, y en ese tipo de conflicto SCO tiene un tiempo medio de finalización de la transacción más corto y un mejor rendimiento que SS2PL. Mientras que SS2PL obedece a la tabla de compatibilidad de bloqueos anterior, SCO tiene la siguiente tabla:

Tenga en cuenta que aunque SCO libera todos los bloqueos al final de la transacción y cumple con las reglas de bloqueo 2PL, SCO no es un subconjunto de 2PL debido a su diferente tabla de compatibilidad de bloqueos. SCO permite conflictos materializados de lectura-escritura entre dos transacciones en sus fases 1, lo que 2PL no permite en la fase 1 (ver sobre conflictos materializados en Serializability). Por otro lado, 2PL permite otros tipos de conflictos materializados en la fase 2 que SCO no permite en absoluto. En conjunto, esto implica que las clases de programación 2PL y SCO son incomparables (es decir, ninguna clase contiene a la otra clase).

Resumen – Relaciones entre clasesEditar

Contención de clases de horario: Una flecha de la clase A a la clase B indica que la clase A contiene estrictamente a la B; la falta de un camino dirigido entre las clases significa que las clases son incomparables. Una propiedad es intrínsecamente bloqueante, si puede ser aplicada sólo bloqueando las operaciones de acceso a datos de la transacción hasta que ocurran ciertos eventos en otras transacciones. (Raz 1992)

Entre dos clases de horario (definidas por las propiedades respectivas de sus horarios) que tienen horarios comunes, una contiene a la otra (estrictamente contiene si no son iguales), o son incomparables. Las relaciones de contención entre las clases 2PL y otras clases de horarios principales se resumen en el siguiente diagrama. 2PL y sus subclases son intrínsecamente bloqueantes, lo que significa que no existen implementaciones optimistas para ellas (y siempre que se menciona «2PL optimista» se refiere a un mecanismo diferente con una clase que incluye también horarios que no están en la clase 2PL).