El protocolo de bloqueo de dos fases asegura, además de la unicidad de los bloqueos para las transacciones incidentes, que aquellos sean proporcionados solo cuando ninguno ha sido adjudicado de vuelta, y que la devolución de los bloques se elabore cuando ninguno esté por concederse. En otras palabras, mientras se concedan bloqueos a transacciones entrantes, no puede ser liberado ninguno por transacciones en curso. De manera similar, cuando se tenga el proceso de liberación de bloqueos, no existirá ninguna transacción en curso que pueda acceder a un nuevo bloque de la información que alguna vez liberó.
Contexto Bloqueos
Un bloqueo es un mecanismo comúnmente utilizado para resolver problemas de sincronización de acceso a información compartida, acopiada en una base de datos. Cada aparte de información que una consulta demanda, requiere de un instante de tiempo en el cual no se ejecuten modificaciones a este bloque asociado, debido a que pueden inducirse errores en lecturas posteriores.
Para ello, previa a la inicialización de una transacción, se examinan los requisitos de información que esta presenta mediante el planificador intrínseco procedente del sistema. Si no existen otras transacciones en curso que se encuentren haciendo uso de los bloques de datos que la nueva transacción solicita, puede brindarse un espacio a aquella para que modifique libremente los apartes de información. A este espacio se le denomina bloqueo, y se encuentra asociado con toda información que sea solicitada en el proceso de consulta (entendiendo consulta como la lectura, modificación y posible actualización de los bloques de datos precisados).
Si existe alguna transacción adicional entrante que requiera la modificación del mismo bloque de información, debe esperar a que la primera de las transacciones libere el bloqueo. Es decir, el planificador no concederá bloques adicionales al mismo aparte de datos que se encuentra en consulta actual. De esta manera, se asegura que únicamente una transacción posea bloqueos para bloques de información, en el tiempo que se encuentre ejecutando las consultas sobre el mismo bloque.
En algunos protocolos de bloqueo, se garantizan acciones preventivas y protectoras a favor de la coherencia en la información consultada de manera que adicional a los bloqueos normalmente deliberados, se afirma que, existen fase adicionales que, mientras el planificador intrínseco se encuentre concediendo bloques a transacciones entrantes, ninguna transacción en curso puede libarlos o alguno de ellos ninguno. Y cuando se tenga el proceso de retorno de bloqueos, no existirá ninguna transacción en curso que pueda solicitar a un bloque nuevo de la misma información que en cierto instante había librado.
Pero a pesar de los esfuerzos por evitar las modificaciones simultáneas a bloques de datos por múltiples transacciones en curso, y de concebir una respuesta evitable a las lecturas sucias, a las actualizaciones perdidas, o a los bloqueos mutuos, no es suficiente esta serie de procedimientos, y es por ello que existe un trasfondo de mayor complejidad sobre los protocolos de bloqueo para prevención de errores fatales de concurrencia, el manejo de información y la caracterización de transacciones en curso.
Administradores y planificadores
Una base de datos, grosso modo, es una colección estructurada de elementos de información que puede ser accedida concurrentemente por diversas transacciones. Estas son conjuntos de operaciones incidentes sobre un aparte de información que transforman el estado consistente de una base de datos. Esto es, las transacciones entendidas por este contexto son unidades completas y computacionalmente correctas que al ser ejecutada de manera única sobre una base de datos consistente, producirán resultados que no afectaran la consistencia de la base de datos. Por ende, el valor intrínseco por definición que identifica la información que una base de datos contiene y que puede ser operada por las transacciones, en términos de tiempo, compromete el estado de la misma debido su afluencia. Por otro lado, un sistema de base de datos (DBS del inglés Database System) es una colección de módulos de Software y Hardware que soportan las operaciones ejecutadas por una transacción. Los usuarios interactúan con el sistema de base de datos mediante las transacciones, y una transacción interactúa con el mundo exterior mediante la emisión de una única operación de lectura o escritura al sistema por medio de las terminales de entrada y salida (I/O).
En consecuencia, los usuarios pueden acceder a la información contenida en una base de datos, mediante la emisión de operaciones de lectura y escritura que el sistema de base de datos permite ejecutar. Un sistema de base de datos se compone de los siguientes componentes: el administrador de transacciones (TM del inglés Transaction Manager), el planificador (S del inglés Scheduler) y el administrador de datos (DM del inglés Data Manager). Un sistema distribuido de base de datos (DDBS del inglés Distributed Database System) es una colección de espacios conectados por una red de comunicaciones los cuales son simples sistemas de base de datos. Cada espacio de un DDMS ejecuta uno o más módulos TM, DM y S. cada uno de ellos, y particularmente el planificador, deben favorecer la consistencia de la base de datos. El administrador de transacciones ejecuta el procesamiento de las operaciones que recibe de las transacciones entrantes, mientras que el planificador controla el orden relativo con el cual estas operaciones son desarrolladas. Entre tanto, el administrador de datos dirige la base de datos en su estado actual. Es decir, cada transacción entrega como resultado un conjunto de operaciones que son dirigidas al administrador de transacciones, el cual recibe este conjunto de procedimientos y los re-envía al planificador. En la figura se ilustra la composición y el comportamiento bidireccional de un sistema de base de datos.
En el sistema distribuido de base de datos, el administrador de transacciones es responsable adicionalmente de la determinación de cuál planificador es más conveniente en el procesamiento de la operación incidente de una transacción. El planificador es responsable de la consistencia de la base de datos, debido a que es quien controla la disposición de las operaciones ejecutadas. Sin embargo, un panificador no es responsable de los procedimientos que ejecuta una transacción, netamente toma en consideración el desarrollo de las operaciones basado en el tipo de proceso y el conjunto de datos relacionado con el mismo.
El planificador controla el orden en que el administrador de datos procesa los procedimientos de lectura y escritura sobre la base de datos. Cuando un planificador recibe este tipo de operaciones del envío del administrador de transacciones, tiene tres opciones: puede resolver la operación con la sencilla respuesta de salida a la misma, retardar la operación mediante el mantenimiento de la misma para acciones posteriores, o rechazar la operación, lo que significaría el rechazo de un aparte de la transacción incidente. Esto deriva en una labor del planificador que desencadena la acción de abortar la transacción que produjo dicha operación cancelada. Asimismo, cualquier otra transacción ajena a esta, que hubiese incluido resultados modificados previos a la cancelación del proceso, tendría que ser de igual manera detenida y abortada.
Esta anomalía en las transacciones para la cual el aborto de una transacción desencadena la cancelación de otra, se denomina abortos en cascada y es prevenida usualmente mediante la asignación de una de las transacciones que requiera el bloque de datos que otra se encuentra modificando. Mientras esta primera no libere los datos en proceso de modificación y asegure la consistencia de la base de datos (mediante una acción de commit), la segunda de las transacciones en curso no podrá hacer uso de aquellos datos. Este proceso de retraimiento se denomina aislamiento.
Comúnmente los planificadores tienen la capacidad de decidir cuál de los tres procedimientos ejecutar: aceptar, retardar o cancelar una operación recibida por una transacción en curso. Desde otro punto de vista, pueden precisarse algunos tipos específicos de planificadores con los cuales se ve favorecida una acción particular de ejecución sobre la base de datos. Basado en el procedimiento de beneficio de que cada uno de los planificadores desarrolla, puede hacerse una distinción entre dos grandes grupos: los planificadores conservativos y los agresivos o certificadores. Un planificador agresivo tiende a evitar acciones de retardo, atraso o aplazamiento, y se enfoca en su inmediata planeación y ejecución.
Pero en la medida en que lo hace, pierde la oportunidad de cambiar el orden de operaciones que recibe un instante posterior. Al renunciar a la oportunidad de cambiar el orden de las operaciones inmediatas, puede verse envuelto en un proceso sin salida en el que no tiene ninguna expectativa de terminar la ejecución de todas las operaciones activas de manera serial (serial referido al proceso serializable ejecutado con operaciones relacionadas con el planificador intrínseco del sistema). En este punto, debe recurrir a procedimientos de rechazo de una o más operaciones, provocando de este modo que sean abortadas, en ocasiones innecesarias, algunas transacciones en curso. Un planificador conservativo, por otro lado, tiende al retardo de las operaciones entrantes procedentes de las transacciones en curso. Esto le permite obtener un margen de acción relativo para reordenar el conjunto de operaciones recibidas posteriormente. Este margen lo hace menos propenso a atascos repentinos.
En casos extremos, el planificador conservativo retrasa la totalidad de las transacciones y da paso a una sola de ellas. Cuando aquella finaliza, otra es seleccionada para continuar con su proceder. Por ello, este planificador procesa las transacciones de manera serial y no requiere la cancelación o aborto de cualquiera de las operaciones en curso, pero evita tales anulaciones en ocasiones un tiempo excesivo de retraso, lo que puede aumentar en gran medida el tiempo de finalización de una o más transacciones.
El administrador de datos ejecuta cada operación de lectura y escritura que recibe. Para una acción de lectura, el administrador examina la base de datos local y retorna el valor requerido solicitado por dicha acción. En la escritura, el administrador modifica la base de datos local y retorna una acción de reconocimiento que indica el ejercicio de escritura desarrollado. Estas acciones del administrador de datos, sea de retorno de valor o de reconocimiento, son acopiadas por el planificador el cual las devuelve al administrador de transacciones, quien las envía de vuelta a la transacción que requirió la tarea de lectura o modificación ejecutada.