Tipos de bloqueos en el control de concurrencia

Las demandas comerciales para garantizar una funcionalidad fluida y servidores de tiempo de ejecución altamente eficientes hacen que sea muy importante para los diseñadores de bases de datos desarrollar sistemas y códigos que eviten hábilmente cualquier tipo de inconsistencias en las transacciones de múltiples usuarios, si no dudan del estándar de administración de memoria en lectura. -bases de datos pesadas, de escritura pesada y todas esas bases de datos comerciales. Este artículo brindará una introducción adecuada a la arquitectura de bloqueo clásica que se propuso e implementó para la comunidad de desarrolladores de bases de datos. 

Deberíamos intentar pasar por alto las técnicas de bloqueo en general, es decir, en función de la granularidad o nivel de la base de datos. Esto es para que podamos tratarlo por separado cuando analicemos la viabilidad de los tipos de cerraduras.

Definición:
La definición formal de una cerradura es la siguiente: 

Un bloqueo es una variable asignada a cualquier elemento de datos para realizar un seguimiento del estado de ese elemento de datos de modo que se asegure el aislamiento y la no interferencia durante las transacciones simultáneas.

Básicamente, existe un bloqueo de la base de datos para evitar que dos o más usuarios de la base de datos realicen cambios en el mismo elemento de datos al mismo tiempo. Por lo tanto, es correcto interpretar esta técnica como un medio para sincronizar el acceso, lo que contrasta fuertemente con otros conjuntos de protocolos, como los que usan sellos de tiempo y sellos de tiempo multiversión. En términos sencillos, esto puede simplificarse aún más al «bloqueo» metafórico que se coloca en un elemento de datos para que ningún otro usuario pueda desbloquear la capacidad de realizar cualquier consulta de actualización.

Caso 1: No se permite el acceso simultáneo a transacciones. Caso 2: poner un candado en otras transacciones es factible

En el Caso 2, que se ha representado anteriormente, si el usuario/sesión de la derecha intenta una actualización, se encontrará con un estado de ESPERA DE BLOQUEO o, de lo contrario, se DETENDRÁ hasta que se desbloquee el acceso al elemento de datos. En algunas situaciones, si la parada supera un límite de tiempo, la sesión finaliza y se devuelve una declaración de error.

Veremos las múltiples formas en que estos bloqueos se han introducido en la industria como soluciones a la concurrencia en las transacciones.

Bloqueos binarios:
recuerda que un bloqueo es fundamentalmente una variable que tiene un valor. Un bloqueo binario es una variable capaz de contener solo 2 valores posibles, es decir, un 1 (que representa un estado bloqueado) o un 0 (que representa un estado desbloqueado) . Este bloqueo generalmente se asocia con cada elemento de datos en la base de datos (tal vez a nivel de tabla, nivel de fila o incluso a nivel de base de datos completa). 

Si el elemento X está desbloqueado, el objeto correspondiente lock(X) devolverá el valor 0. Por lo tanto, en el instante en que un usuario/sesión comienza a actualizar el contenido del elemento X, lock(X) se establece en un valor de 1. Debido a esto, mientras dure la consulta de actualización, ningún otro usuario puede acceder al elemento X, ¡ni siquiera leerlo o escribirlo! 

Hay 2 operaciones que se utilizan para implementar bloqueos binarios. Son lock_data() y unlock_data(). Los algoritmos se han discutido a continuación (solo los algoritmos se han entretenido debido a la diversidad en las secuencias de comandos DBMS):

La operación de bloqueo:

lock_data(X):
label:    if lock(X) == 0
        {
            then lock(X) = 1;
        }
        else //when lock(X) == 1 or item X is locked
        {            
            wait (until item is unlocked or lock(X)=0) //wait for the user to finish the update query
            go to label
        }

Tenga en cuenta que ‘ label: ‘ es literalmente una etiqueta para la línea a la que se puede hacer referencia en un paso posterior para transferir la ejecución. El comando ‘esperar’ en el bloque else básicamente pone todas las demás transacciones que desean acceder a X en una cola. Dado que supervisa o mantiene programadas otras transacciones hasta que se desbloquea el acceso al elemento, a menudo se considera que está fuera de la operación lock_data(X), es decir, definido fuera.

 La operación de desbloqueo:

unlock_data(X):
    lock(X) = 0 //we unlock access to item X
    if (transactions are in queue)
    {    
        then grant access or 'wake' the next transaction in line;
    }

Ventajas de los bloqueos binarios:

  • Son sencillos de implementar ya que son efectivamente mutuamente excluyentes y establecen perfectamente el aislamiento.
  • Los bloqueos binarios demandan menos del sistema ya que el sistema solo debe mantener un registro de los elementos bloqueados. El sistema es el subsistema del administrador de bloqueos, que es una característica de todos los DBMS en la actualidad.

Inconvenientes de los bloqueos binarios:

  • Los bloqueos binarios son muy restrictivos.
  • Ni siquiera permiten la lectura del contenido del ítem X. Por lo tanto, no se utilizan comercialmente.

Bloqueos compartidos o exclusivos:
el incentivo que rige este tipo de bloqueos es la naturaleza restrictiva de los bloqueos binarios. Aquí observamos los bloqueos que permiten que otras transacciones realicen consultas de lectura, ya que una consulta de LECTURA no genera conflictos . Sin embargo, si una transacción exige una consulta de escritura en el elemento X, entonces esa transacción debe tener acceso exclusivo al elemento X. Ergo, necesitamos un tipo de bloqueo multimodo, que es lo que son los bloqueos compartidos/exclusivos. También se conocen como bloqueos de lectura/escritura.

A diferencia de los bloqueos binarios, los bloqueos de lectura/escritura se pueden establecer en 3 valores, es decir, COMPARTIDO , EXCLUSIVO o DESBLOQUEADO . Por lo tanto, nuestro candado, es decir, candado(X), puede reflejar cualquiera de los siguientes valores:

  1. LECTURA BLOQUEADA:
    si una transacción solo requiere leer el contenido del elemento X y el bloqueo solo permite la lectura. Esto también se conoce como bloqueo compartido .
  2. ESCRITURA BLOQUEADA:
    si una transacción necesita actualizarse o escribirse en el elemento X, el bloqueo debe restringir todas las demás transacciones y proporcionar acceso exclusivo a la transacción actual. Así, estos bloqueos también se conocen como bloqueos exclusivos .
  3. DESBLOQUEADO:
    una vez que una transacción ha completado sus operaciones de lectura o actualización, no se mantiene ningún bloqueo y el elemento de datos se desbloquea. En este estado, cualquier transacción en cola puede acceder al artículo.

Un candado Compartido/Exclusivo puede contener cualquiera de los 3 estados.

La forma más popular de implementar estos bloqueos es mediante la introducción de una TABLA DE BLOQUEOS que realiza un seguimiento del número de bloqueos de lectura en los elementos de datos y las transacciones con bloqueos de escritura en diferentes elementos. La tabla se describe a continuación.

Tenga en cuenta que si un elemento está bloqueado contra escritura, lógicamente se supone que no tiene lecturas debido al hecho de que ahora es exclusivo. Como resultado, la columna ‘Transacción de bloqueo’ contiene solo un valor: el ID de transacción de la transacción actual. Si un elemento tiene bloqueo de lectura, varias transacciones lo comparten y, por lo tanto, la columna «Transacción de bloqueo» enumera los ID de transacción de todas las transacciones. Dado que hay 3 estados que el bloqueo puede contener, debe haber 3 operaciones que ejecutarían el cambio a esos estados. Estos son los siguientes:

La operación read_lock –

read_lock(X):
label:  if lock(X) = "unlocked"
        {
            then lock(X) = "read-locked";
            no_of_reads = 1; //since only the first transaction in queue is now able to read item X
        }
        else if lock(X) = "read-locked"
        {
            then no_of_reads +=1; //simply increment as a new transaction is now reading the item X
        }
        else //lock(X) write-locked
        {
            wait (until lock(X) is "unlocked");//transactions observe a LOCK WAIT during this time
            go to label;
        }

Cuando el bloqueo (X) se establece en «bloqueado contra escritura» (en la cláusula else final), el elemento está siendo accedido exclusivamente por una transacción. Para que otras transacciones accedan a él, la ESPERA DE BLOQUEO debe finalizar (el proceso de actualización debe finalizar) y bloquear (X) = «desbloqueado». Esto es lo que esperamos en la siguiente línea.

La operación write_lock –

write_lock(X):
label:  if lock(X) = "unlocked"
        {
            then lock(X) = "write-locked"
        }
        else //if a read-lock is issued to item X
        {
            wait (until lock(X) is "unlocked"); //so that the lock manager may wake up the next transaction
            go to label;
        }

Si un artículo está desbloqueado, simplemente lo bloqueamos contra escritura para otorgar acceso exclusivo a la transacción actual. Ahora el sistema administrador de bloqueos debe poner todas las demás transacciones en una cola. Si el elemento está en un estado de bloqueo de lectura, el bloqueo de escritura NO se puede emitir directamente. Primero se debe desbloquear el elemento antes de que se pueda bloquear contra escritura. Al hacerlo, el sistema del administrador de bloqueos también activa las transacciones en cola.

La operación de desbloqueo –

unlock(X):
    if lock(X) = "write-locked"
    {
        then lock(X) = "unlocked";
        //the transactions in queue, if any, may now access item X in the manner they demand
    }
    else if lock(X) = "read-locked"
    {
        then
            no_of_reads-=1; //the transaction is done reading.
            if no_of_reads == 0 //no transactions reading the item
            {
                lock(X) = "unlocked";
                //transactions in queue, if any, may now access item X in the manner they demand
            }
    }

El primer caso es bastante sencillo. Sin embargo, en el segundo caso, debemos verificar la condición de que no haya más transacciones actuales compartiendo o leyendo el elemento X. Si se está leyendo el elemento X, dejamos la situación y simplemente decrementamos el no_of_reads cuando la última transacción ha terminado. El punto aquí es que un elemento puede «desbloquearse solo si:

  • la operación de ‘escritura’ termina o se completa
  • todas las operaciones de ‘lectura’ terminan o se completan

Aquí hay algunas reglas que deben obedecer los bloqueos compartidos/exclusivos:

  1. Una transacción T DEBE emitir la operación de desbloqueo (X) después de que hayan finalizado todas las operaciones de lectura y escritura.
  2. Una transacción T NO puede emitir una operación de bloqueo de lectura (X) o bloqueo de escritura (X) en un elemento que ya tiene un bloqueo de lectura o escritura emitido para sí mismo.
  3. Una transacción T NO puede emitir la operación de desbloqueo (X) a menos que se haya emitido con una operación de lectura_bloqueo(X) o escritura_bloqueo(X).

Cuando relajamos estas reglas, se puede introducir una nueva dimensión de intercambiar el estado de los bloqueos en los elementos. Esto se ha explicado en el siguiente artículo: Protocolo de control de concurrencia basado en bloqueo en DBMS

Inconvenientes de los bloqueos compartidos/exclusivos:

  • No garantice la serialización de los horarios por sí solos. Se debe seguir un protocolo separado para asegurar esto.
  • Comercialmente no optimizado para transacciones rápidas; no es la mejor solución debido a problemas de contención de bloqueo.
  • La sobrecarga de rendimiento no es despreciable.

Certificar bloqueos:
la motivación detrás de la introducción de certificados de bloqueo es el fracaso de los bloqueos mencionados anteriormente para ofrecer una arquitectura eficiente y prometedora que no comprometa la velocidad de procesamiento de transacciones. Aquí observamos brevemente una forma de esquema de bloqueo de modo múltiple que permite que el bloqueo se caracterice por 3 estados bloqueados y 1 estado desbloqueado

Las transacciones pueden emitir cualquiera de los 3 estados bloqueados o 1 estado desbloqueado

Los estados en los que se puede emitir un artículo son:

  1. BLOQUEO DE LECTURA
    igual que el estado de bloqueo de lectura explicado anteriormente para bloqueos compartidos/exclusivos
  2. ESCRITURA BLOQUEADA
    igual que el estado de escritura bloqueada explicado anteriormente para bloqueos compartidos/exclusivos
  3. CERTIFICAR-BLOQUEADO
    este es un bloqueo exclusivo. Esto se usa cuando se deben leer y escribir 2 transacciones diferentes, respectivamente, en el elemento X. Para que esto suceda, se crea una versión confirmada y una versión local del elemento de datos. La versión comprometida es utilizada por todas las transacciones que tienen un bloqueo de lectura emitido para X. T accede a la versión local de X solo cuando T ha adquirido un bloqueo de escritura. Una vez que la operación de escritura o actualización ha sido realizada por T en el elemento X, T debe obtener un bloqueo de certificado para que la versión comprometida del elemento de datos X pueda actualizarse al contenido de la versión local y la versión local pueda descartarse.
  4. DESBLOQUEADO
    igual que el estado de bloqueo de escritura explicado anteriormente para bloqueos compartidos/exclusivos

Así es como se usa un bloqueo certificado en técnicas de control de concurrencia de múltiples versiones:

En el Paso 2, se crean dos versiones del Elemento X, es decir, las versiones local y confirmada. En el Paso 4, la transacción debe emitir un bloqueo certificado en todas las escrituras que haya realizado. Solo entonces podemos pasar al siguiente paso. Las actualizaciones de la versión local ahora son definitivas.

Paso 5

Para que múltiples transacciones accedan al contenido del elemento de datos X, se debe dibujar una tabla de compatibilidad para que no se devuelva ninguna colisión o error, lo que puede retrasar el proceso. 

Bloqueos en X

    Leer         Escribe       Certificar  
        Leer         

No

        Escribe

No

No

       Certificar

No

No

No

La forma correcta de interpretar esta tabla es la siguiente. Considere dos transacciones, T y T’ . Asigne la transacción T a las filas o las columnas. Haz exactamente lo contrario para T’. Ahora la compatibilidad entre los bloqueos emitidos a un artículo X por T y T’ se puede cruzar. Por ejemplo, asigne T a las filas y T’ a las columnas. Si T emite un bloqueo de lectura en X y T’ emite un bloqueo de escritura en X, el resultado es un ‘Sí’: este escenario es factible. Sin embargo, si T pretende un bloqueo de escritura en X y T’ pretende un bloqueo de certificación en X, el resultado es un ‘No’, lo que implica un escenario imposible.

Hay otros temas que analizan el desarrollo de técnicas mejores y avanzadas para manejar el control de concurrencia, como marcas de tiempo , modelos multiversión de elementos de datos y aislamiento de instantáneas. Sin embargo, comprender la base de la idea es clave cuando se trata de construir una comprensión clara de conceptos que pueden ser tan complejos como el control de concurrencia.

Publicación traducida automáticamente

Artículo escrito por siddhant_baroth y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *