Bloqueo de dos fases

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.

Se ha sugerido que este artículo sea separado en los siguientes artículos: Administrador de transacciones, Planificador de transacciones y Administrador de datos (discusión). Una vez que hayas realizado la separación de artículos, indica tú mismo la procedencia del nuevo artículo en el resumen de edición y en su página de discusión mediante la plantilla {{separado de}}.

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.

Las operaciones de lectura y escritura demandadas por transacciones incidentes sobre bloques de datos x se denotan mediante Ri[x] y Wi[x], respectivamente. Con la operación de lectura Ri[x] se establece como resultado el valor almacenado del bloque de datos x requerido por la transacción en curso Ti. La operación de escritura Wi[x] modifica y actualiza el valor propio del bloque de información solicitado y se establece en la base de datos este nuevo resultado, devolviendo el valor reciente a la transacción Ti que lo exigió. Las operaciones de lectura no tienen efecto sobre la consistencia de la base de datos, debido a que no existen procedimientos que transformen internamente la información. Por otro lado, las operaciones de escritura causan cambios en el estado de la base de datos puesto que la información que se solicita por una transacción será posteriormente actualizada internamente en la base de datos. Operaciones de lectura y escritura pertenecientes a diferentes transacciones que confluyen en planificadores comunes entran en conflicto cuando se deben ejecutar procedimientos de actualización y modificación que impliquen los mismos bloques de datos.

El conjunto de lectura de una transacción, denotado como S(Ri), es la agrupación de apartes de información que una transacción requiere para la lectura, mientras que el conjunto de escritura de una transacción, marcado como S(Wi), es la agrupación de bloque de datos que una transacción requiere para su escritura. El conjunto de acceso o base de una transacción es la unión de sus conjuntos de lectura y escritura. Cuando dos o más transacciones se ejecutan de forma concurrente, sus operaciones son ejecutadas en forma intercalada.

Cada transacción empieza con una operación de inicio y termina con una operación de confirmación o de cancelación. La confirmación (commit) indica que la transacción ha completado su ejecución y los efectos de las operaciones desarrolladas en función de dicha transacción sobre la base de datos, tales como modificaciones y actualizaciones continuas, son permanentes. La cancelación indica que la transacción se ha completado de manera irregular y por ende los efectos por esta son reversados por medio de la reincorporación de los antiguos valores que los bloques de datos poseían en un principio previo a la conexión de la transacción.

El protocolo de confirmación más común es el protocolo de confirmación de dos fases (2PC). En la primera fase, los valores de los bloques de datos pertenecientes al conjunto de escritura de la transacción son almacenados en espacios libres de manipulación, sin sobrescribir los valores antiguos. En esta fase, la transacción solicita procedimientos de confirmación al planificador, el cual procede a la preparación de los procesos participantes en la transacción para que den lugar a los procedimientos adecuados para confirmación o cancelación de la transacción, basado en la consistencia de cada porción de procesos participantes.

Si la primera fase termina exitosamente, la transacción finaliza y no podrá ser cancelada por ninguna circunstancia. Hecho esto, un mensaje de finalización es enviado a los servidores relacionados y los efectos de la transacción quedan permanentes mediante la escritura de los valores anexados del almacenamiento hacia la base de datos.

En la segunda fase, teniendo en cuenta la consistencia de cada porción de procesos participantes, el planificador rigurosamente decide las acciones requeridas para ejecutar procedimientos de confirmación o cancelación definitivos, haciendo uso de los recursos transaccionales. Si ocurre una falla durante la primera fase, la transacción es abortada, y los valores copiados en el almacenamiento son omitidos radicalmente. Si la transacción falla durante la segunda fase, no es requerida la cancelación; sin embargo, los valores copiados en el almacenamiento son escritos en la base de datos cuando el espacio que ha fallado se recupere. Mediante el uso del 2PC, también se pueden evitar los abortos en cascada, debido a que las operaciones de escritura son aplicadas a la base de datos únicamente cuando las transacciones finalizan y la base de datos permanece en un estado consistente.

Pero en muchas ocasiones los planificadores denotan facetas de versiones agresivas y conservativas. En términos generales, un planificador conservativo trata de anticipar el futuro comportamiento de una transacción, a fin de prepararse para operaciones que aún no han sido recibidas. La información principal que necesita reconocer es el conjunto de bloques de datos con el cual cada transacción solicitara operaciones de lectura y escritura. De esta manera, el planificador puede predecir cuáles de las operaciones que están programadas en el presente pueden entrar en conflicto con los procedimientos que llegarán en el futuro.

En contraste, un planificador agresivo no requiere información del conjunto de bloques de datos, dado que programa las operaciones tan pronto como es posible, evitando retardos y/o atrasos, apoyándose en la cancelación transaccional para corregir posibles errores repentinos. Un planificador conservativo puede usualmente ser desarrollado si las transacciones declaran por anticipado sus conjuntos de lectura y escritura. Esto es, que el Administrador de Transacciones procese transacciones, entregando al planificador el conjunto de lectura y escritura de aquellas. Esta declaración adelantada puede ser consumada más eficazmente si las transacciones son detalladas por un pre-procesador, tal como un compilador, antes de iniciar el envío al sistema, en lugar de ser interpretadas sobre la marcha.

Una de las dificultades existentes que impide la constitución exitosa de planificadores conservativos se presenta cuando se encuentran en ejecución procedimientos que impliquen transacciones que accedan a diferentes conjuntos de bloques de datos. Esto ocurre si los procedimientos contienen declaraciones condicionales. Por ejemplo, el programa siguiente ejecuta una lectura sobre las variables x, y, z:

Start;

m∶ = Read(x);

if (m<0) then n∶ = Read(y) else n∶ = Read(z);

Commit

End

En este caso, la transacción debe declarar anticipadamente el conjunto de bloques de datos disponibles para sus acciones de lectura o escritura, lo que usualmente causa se extreme en la selección de dichos conjuntos. En el ejemplo anterior, la transacción en curso pudiera declarar el conjunto de lectura como {x,y,z}, a pesar de que de cualquier forma, la ejecución solo tendrá acceso únicamente a dos de esos tres bloques de datos. En general, una consulta puede potencialmente acceder a grandes porciones de la base de datos, aunque en una sola ejecución acceda a una pequeña fracción de la misma.

Cuando diversas transacciones cuyas operaciones requeridas presentan cuantiosos conjuntos de bloques de datos de lectura y escritura que requieren una declaración previa deben ser tenidas en cuenta, el planificador termina siendo incluso más conservativo de lo que debe ser, y por ende, en lugar de predecir y acelerar los procedimientos requeridos, retrasará ciertas operaciones mientras intenta anticiparse a otras que nunca serán emitidas. Adicionalmente, si los requerimientos de información son solicitados por múltiples conexiones que implican transacciones que apunten a un mismo bloque de datos, debe tenerse especial precaución en el tiempo en que las transacciones conecten. Esto es, si se encuentran en curso diversas transacciones que presentan exigencias de apartes de información idénticos, se presentarán situaciones de concurrencia de transacciones, lo que puede incurrir, en algunos casos, en errores de carácter relevante que no podrán sobrellevarse satisfactoriamente por el planificador, y en consecuencia, debido a que no se tiene control sobre los datos modificados, la base de datos podría permanecer, con una alta probabilidad, en un estado inconsistente, lo que puede ser catastrófico para los requerimientos de transacciones futuras y para el futuro del sistema. Debido a esto, el control de concurrencia es fundamental en un sistema de base de datos, y puede ser administrado por protocolos que bloqueen, por instantes determinados, el acceso y modificación de la información solicitada.

En los entornos de administración global la mayoría de bases de datos permiten, con considerable aceptación, la concurrencia de múltiples conexiones. Situaciones como interacciones de diversos usuarios con variados bloques de datos ubicados en bases de datos son naturalmente permitidas. Pero particularmente aquellos casos en los cuales las transacciones que se ejecutan constantemente por usuarios que presentan conexiones con instancias de una misma base de datos, y que requieren la modificación de un bloque de datos específico, deben administrarse con mayor precaución con el fin de prevenir inconsistencias posteriores en la base de datos.

Por ejemplo, las situaciones que pueden presentarse cuando se tienen en cuenta los objetivos principales que conllevan a un usuario a la conexión con una base de datos, y a la posterior ejecución de instrucciones mediante operaciones transaccionales son:

- Un usuario inicia la conexión con la base de datos, y el planificador recibe un conjunto de instrucciones procedentes de las transacciones que éste ejecuta. Una de las operaciones implica la modificación de uno de los bloques de datos almacenados en la base de datos. Mientras la transacción se encuentra en curso, un segundo usuario se conecta a la misma instancia de la base de datos con el fin de ejecutar una serie de operaciones transaccionales que contengan lecturas del bloque de datos que el primero de los usuarios se encuentra actualizando.

- Un usuario inicia la conexión con la base de datos, y el planificador recibe un conjunto de instrucciones procedentes de las transacciones que éste ejecuta. Una de las operaciones implica la modificación de uno de los bloques de datos almacenados en la base de datos. Simultáneamente, un segundo usuario se conecta a la misma instancia de la base de datos con el fin de ejecutar una serie de operaciones transaccionales que contengan actualizaciones del bloque de datos que el primero de los usuarios se encuentra modificando.

- Un usuario inicia la conexión con la base de datos, y el planificador recibe un conjunto de instrucciones procedentes de las transacciones que éste ejecuta. Las operaciones implican lecturas y actualizaciones sucesivas sobre uno de los bloques de datos almacenados en la base de datos. Simultáneamente, un segundo usuario se conecta a la misma instancia de la base de datos con el fin de ejecutar una serie de operaciones transaccionales que involucren la eliminación de uno de los bloques de datos que el primero de los usuarios se encuentra solicitando, leyendo y actualizando.

Teniendo en cuenta estas circunstancias, pueden presentarse sin dudas conflictos que afecten la consistencia de la base de datos, y la información en sí. Debido a esto, los sistemas de bases de datos deben prever estas situaciones, y en caso de que se presenten, deben estar desarrolladas estructuralmente sólidas con algoritmos que puedan resolver estos inconvenientes sin comprometer la consistencia de la información. El conjunto de procedimientos de evasión y posterior solución de este tipo de inconvenientes se denomina control de concurrencia. Si el propósito del acceso simultáneo de múltiples usuarios a una base de datos, es el de ejecución de operaciones transaccionales de lectura de entrada y salida, no existirán mayores inconvenientes generales en términos de la consistencia de los datos consultados. Mas si el objetivo concerniente con la anterior situación implica adicionalmente acciones transaccionales de actualización de contenido, entonces deberán implementarse controles de concurrencia.

Considérese la siguiente situación: dos usuarios A y B de Departamentos X y Y, respectivamente, se encuentran simultáneamente con conexión a una base de datos cuyos requerimientos transaccionales implican actualizaciones del mismo contenido de información. Cabe aclarar que por imposiciones internas del sistema de base de datos existen procedimientos de bloqueo de subnivel que impiden que las transacciones se ejecuten exactamente en el mismo instante, por lo que se asumirá que el usuario A precede al B.

Considérese también que las operaciones de actualización se basan en modificaciones del inventario de 300 productos de un establecimiento centralizado en una organización. Asúmase que las transacciones del usuario del departamento X se ejecutan con el fin de retirar 250 unidades de un artículo específico incluido dentro del inventario del establecimiento para su propio beneficio. De manera similar, las transacciones del usuario del departamento Y se ejecutan con el fin de retirar 150 unidades del mismo artículo incluido dentro del inventario del establecimiento.

Cuando exista un acceso de un usuario de cualquiera de los departamentos, debe validarse que el inventario en el establecimiento sea mayor al requerido por el propio departamento. Si es así, se generará una instrucción dirigida al establecimiento para que sea retirada del inventario, la cantidad necesaria de artículos concernientes con la petición. De esta maneara, el inventario resultante en el establecimiento será la sustracción entre la cantidad de artículos de inventario en el establecimiento, y la cantidad del conjunto de artículos requeridos por el departamento. Si la transacción del usuario A se encuentra primero en curso, el inventario general que verá en el establecimiento será de 300 artículos, lo cual es suficiente para los requerimientos internos de inventario que presupone. Por ende, la cantidad de elementos restantes será 25, actualización que será registrada posteriormente en los registros de la base de datos.

En la ausencia de controles de concurrencia administrados sobre la base de datos, en algún instante, la transacción del usuario asignado para el departamento Y entrará en curso. Esto podría ocurrir inmediatamente después de la finalización de las operaciones de nivelación de inventario que la primera de las transacciones propuso, lo que indica que las actualizaciones ejecutadas por estas consultas no han sido almacenadas en registros internos. Al continuar la segunda transacción en curso, el usuario evidencia una cantidad de artículos en inventario de 300, lo cual es suficiente para los requerimientos internos que este departamento presupone. La cantidad de elementos restantes será 150, actualización que será registrada posteriormente en los registros de la base de datos.

La acción ejecutada por este último usuario del departamento, al finalizar las operaciones transaccionales y el almacenamiento de los registros restantes, dará como resultado un inventario final en el establecimiento de 150 artículos, una cantidad de bienes en el departamento X nula, y en el departamento Y de 150. Esto conlleva a concluir que al finalizar las operaciones transaccionales y conexiones con la base de datos, las acciones de actualización ejecutadas por el departamento X han sido canceladas por la inicialización de las transacciones del departamento Y, y el número de artículos en inventario posterior a la demanda del departamento X, que debió haber sido de 50 restantes, lo que hubiera dejado al departamento X sin artículos para surtimiento, es en realidad la cantidad original, debido a que se ha cancelado el pedido, sorpresivamente, del primer usuario. Como resultado, ambas transacciones afectan negativamente la consistencia de la información y de la base de datos. Algunos métodos para corregir estos errores indebidos y que afectan la integridad del sistema son los recursos de bloqueo.

Los inconvenientes de inconsistencia que se presentan sobre la base de datos cuando no existen controles para las transacciones de los usuarios pertenecientes a los departamentos ejemplificados al estos acceder de manera concurrente, pueden ser evadidos mediante bloqueos de requerimiento. Estos se hacen válidos cuando la transacción procedente del usuario del departamento X es iniciada, y liberados en el instante en que cada registro del resultado de las operaciones transaccionales de esta transacción sean actualizados internamente en la base de datos, de manera que el acceso al información por parte del usuario del departamento Y le sea denegada mientras la transacción inicial incidente no haya finalizado con la actualización de registros (protocolo de confirmación).

Los procedimientos ejecutados con el fin de obtener actualizaciones significativas, válidas y significativas en la información contenida en una base de datos, con respecto a la situación denotada, se muestra en seguida:

  1. Identificar los requerimientos de información que la transacción del usuario del departamento X solicita.
  2. Bloquear los bloques de información solicitados.
  3. Ejecutar una lectura de los bloques de información bloqueados y exponerlos al manejo del planificador.
  4. Actualizar el contenido del recurso de información utilizado.
  5. Escribir las actualizaciones en el registro interno de la base de datos.
  6. Desbloquear los bloques de datos solicitados para el desarrollo satisfactorio de otras transacciones incidentes que puedan requerirlos (desbloquear los bloques de datos para que el usuario del departamento Y pueda desarrollar las operaciones transaccionales libre y consistentemente).

Debido a estas situaciones, es claro que la administración de los recursos de información propuestos y dispuestos a consultas por medio de operaciones transaccionales debe basarse en controles de concurrencia válidos que sean basados en procedimientos de bloqueo y desbloqueo continuos. Sin embargo, en una base de datos los bloqueos deben ejecutarse en diferentes niveles. El grado de bloqueo al cual se encuentran sometida la información de una base de datos se denomina granularidad del bloqueo. Si la información que se encuentra bloqueada corresponde a la totalidad de la base de datos, el grado de bloqueo es grueso (granularidad gruesa). Si por otro lado existe un aparte mínimo de información bloqueada, el grado de bloqueo es fino (granularidad fina).

Los procedimientos de bloqueo pueden ejecutarse sobre bloques de datos singulares pertenecientes a un conjunto de datos embebido sobre la base de datos, lo que le permite a un usuario acceder a un bloque de datos, mientras otro usuario solicita uno distinto, aunque ambos pertenezcan al mismo conjunto de datos. Esta acción de bloqueo, si bien es válida y útil, representa un gasto de implementación muy elevado, y controles adicionales que en ocasiones no pueden ser suplidos con rapidez. Por tal razón, es de mayor facilidad bloquear el conjunto de datos grupalmente, mientras un usuario se encuentre accediendo a un bloque de datos individualizado dentro de éste. De esta manera, un segundo usuario que requiere otro bloque de datos distinto, pero que se encuentre inmerso en el mismo conjunto de datos, se verá obligado a ejecutar procedimientos de espera con el fin de conseguir la información que requiere, pero que se encuentra bloqueada por operaciones transaccionales del primero de los usuarios.

Por ende, la primera opción de procedimiento de bloqueo implica a las transacciones menor tiempo de espera para los requerimientos de información, pero resulta en gastos mayores en los ámbitos de procesamiento e implementación. El segundo, sin embargo, aunque conlleva a un mayor tiempo de espera por deliberación de operaciones transaccionales, es relativamente simple de implementar, lo que aumenta la capacidad de procesamiento y velocidad. Existen cuatro tipos fundamentales de bloqueos transaccionales: Bloqueos Binarios, Bloqueos S/X, Bloqueos de Certificación y Bloqueos de Intención. Los Bloqueos Binarios poseen dos estados de bloqueo: Bloqueado y Desbloqueado, de gran restricción y simpleza que efectúa exclusiones mutuas sobre bloques de información transaccionales, lo que los hace poco usados a nivel de implementación.

Toda transacción bajo este tipo de bloque debe seguir los siguientes criterios administrativos:

- Una transacción T debe solicitar una operación de bloqueo sobre un bloque de datos previa a cualquier acción de lectura o escritura ejecutadas sobre aquella información.

- Una transacción T debe solicitar una operación de desbloqueo sobre un bloque de datos posterior a todas aquellas acciones de lectura y/o escritura que debiera ejecutar durante su conexión.

- Una transacción T nunca debe solicitar una operación de bloqueo sobre un bloque de datos si ya posee cualquier tipo de bloque sobre el mismo.

- Una transacción T nunca debe solicitar una operación de desbloqueo sobre un bloque de datos si no posee tipo alguno de bloque sobre el mismo bloque de información.

A diferencia de los Bloques Binarios, los Bloqueos S/X se componen de dos sub-tipos de bloqueo: Bloqueo Compartido (Bloque S) o Bloqueo de Lectura, y Bloqueo Exclusivo (Bloqueo X) o Bloqueo de Escritura. Si una transacción obtiene un Bloqueo Compartido sobre un conjunto de datos pertenecientes a una base de datos, significa que puede ejecutar lecturas sucesivas sobre la información, pero en ninguna instancia del proceso transaccional podrá desarrollar actualizaciones sobre esta información. Por otro lado, si una transacción obtiene un Bloqueo Exclusivo sobre un conjunto de datos pertenecientes a una base de datos, significa que puede ejecutar operaciones de escritura y lectura sucesivas sobre la información.

Cuando una transacción requiere ejecutar operaciones de lectura o escritura que impliquen bloques de datos almacenados en una base de datos, se procede a conceder el bloqueo sobre el recurso de información, si no existen transacciones en curso que hayan obtenido el bloqueo sobre el miso aparte de datos.

Por ende cuando una transacción solicita un bloqueo de información procedente de una base de datos, este puede ser concedido teniendo en cuenta las siguientes condiciones:

  1. Ninguna transacción se encuentra en espera de la liberación de un bloqueo que alguna otra transacción en curso ha solicitado.
  2. Si se trata de un Bloqueo Compartido, ha de verificar que ninguna otra transacción se encuentre haciendo uso de la información mediante Bloqueos Exclusivos. Si las transacciones en curso concurren y solicitan Bloqueos de Lectura podrán ser concedidos a todas aquellas, así el conjunto de datos sea símil.

Si se trata de un Bloqueo Exclusivo, ha de verificar que ninguna otra transacción se encuentre haciendo uso de la información mediante cualquier tipo de bloqueo se un Bloqueo Exclusivo o un Bloqueo Compartido.