El protocolo basado en validación también se denomina técnica de control de concurrencia optimista. Este protocolo se utiliza en DBMS (Database Management System) para evitar la concurrencia en las transacciones. Se llama optimista debido a la suposición que hace, es decir, se produce muy poca interferencia, por lo tanto, no hay necesidad de verificar mientras se ejecuta la transacción.
En esta técnica, no se realiza ninguna verificación mientras se ejecuta la transacción. Hasta que se alcanza el final de la transacción, las actualizaciones en la transacción no se aplican directamente a la base de datos. Todas las actualizaciones se aplican a las copias locales de los elementos de datos guardados para la transacción. Al final de la ejecución de la transacción, durante la ejecución de la transacción, una fase de validación verifica si alguna de las actualizaciones de la transacción viola la serialización. Si no hay violación de la serialización, la transacción se confirma y la base de datos se actualiza; o bien, la transacción se actualiza y luego se reinicia.
Optimistic Concurrency Control es un protocolo de tres fases. Las tres fases del protocolo basado en la validación:
- Fase de lectura:
una transacción puede leer los valores de los elementos de datos confirmados de la base de datos. Las actualizaciones solo se aplican a las versiones de datos locales.
- Fase de validación:
se realiza una verificación para asegurarse de que no haya una violación de la serialización cuando se aplican las actualizaciones de transacciones a la base de datos.
- Fase de escritura:
si la fase de validación tiene éxito, las actualizaciones de la transacción se aplican a la base de datos; de lo contrario, las actualizaciones se descartan y la transacción se ralentiza.
La idea detrás de la concurrencia optimista es hacer todas las comprobaciones a la vez; por lo tanto, la ejecución de la transacción procede con un mínimo de sobrecarga hasta que se alcanza la fase de validación. Si no hay mucha interferencia entre las transacciones, la mayoría de ellas tendrán una validación exitosa, de lo contrario, los resultados se descartarán y se reiniciarán más tarde. Estas circunstancias no son muy favorables para las técnicas de optimización, ya que no se cumple el supuesto de menor interferencia.
El protocolo basado en la validación es útil para conflictos raros. Dado que solo se incluyen copias locales de datos en las reversiones, se evitan las reversiones en cascada. Este método no es favorable para transacciones más largas porque es más probable que tengan conflictos y pueden revertirse repetidamente debido a conflictos con transacciones cortas.
Para realizar la prueba de Validación, cada transacción debe pasar por las distintas fases descritas anteriormente. Luego, debemos conocer los siguientes tres sellos de tiempo que le asignamos a la transacción Ti , para verificar su validez:
1. Inicio(T i ): Es el momento en que Ti inició su ejecución.
2. Validación (T i ): Es el momento en que Ti acaba de terminar su fase de lectura y comienza su fase de validación.
3. Finalizar (T i ): el momento en que T i finaliza todas las operaciones de escritura en la base de datos en fase de escritura.
Dos términos más que necesitamos saber son:
1. Write_set: de una transacción contiene todas las operaciones de escritura que realiza Ti .
2. Read_set: de una transacción contiene todas las operaciones de lectura que realiza Ti .
En la fase de Validación de la transacción Ti , el protocolo inspecciona que Ti no se superponga ni intervenga con ninguna otra transacción que se encuentre actualmente en su fase de validación o comprometida. La fase de validación para T i verifica que para toda transacción T j una de las siguientes condiciones a continuación debe cumplir para ser validada o pasar la fase de validación:
1. Finish(T j )<Starts(T i ) , ya que T j finaliza su ejecución significa que completa su fase de escritura antes de que T i comenzara su ejecución (fase de lectura). Entonces la serialización de hecho se mantuvo.
2. Ti comienza su fase de escritura después de que Tj completa su fase de escritura, y el conjunto_lectura de Ti debe estar disjunto con el conjunto_escritura de Tj .
3. Tj completa su fase de lectura antes de que Ti complete su fase de lectura y tanto el conjunto_lectura como el conjunto_escritura de Ti son disjuntos con el conjunto_escritura de Tj .
Ej: Aquí se dan dos Transacciones Ti y T j , ya que TS(T j )<TS(T i ) por lo que la fase de validación tiene éxito en el Anexo-A. Cabe señalar que las operaciones finales de escritura en la base de datos se realizan solo después de la validación de Ti y T j . Dado que Ti lee los valores antiguos de x(12) e y(15) durante la operación de impresión (x+y) , a menos que tenga lugar la operación de escritura final.
| T j | Yo _ |
|---|---|
| r(x) // x=12 | |
| r(x) | |
|
x=x-10 r(y) //y=15 |
|
|
y=y+10 r(x) |
|
|
<validar> imprimir(x+y) |
|
| <validar> | |
|
w(x) w(y) |
1. Evite las reversiones en cascada : este esquema basado en la validación evita las reversiones en cascada, ya que las operaciones finales de escritura en la base de datos se realizan solo después de que la transacción pasa la fase de validación. Si la transacción falla, no se realiza ninguna operación de actualización en la base de datos. Por lo tanto, no ocurrirá ninguna lectura sucia, por lo que las posibilidades de reversión en cascada serían nulas.
2. Evitar interbloqueos : Ya que se utiliza una estricta técnica basada en sellos de tiempo para mantener el orden específico de las transacciones. Por lo tanto, el interbloqueo no es posible en este esquema.
1. Inanición: puede haber una posibilidad de inanición para las transacciones a largo plazo, debido a una secuencia de transacciones a corto plazo en conflicto que causa la secuencia repetida de reinicios de las transacciones a largo plazo y así sucesivamente. Para evitar el hambre, las transacciones en conflicto deben bloquearse temporalmente durante algún tiempo, para permitir que finalicen las transacciones a largo plazo.
Publicación traducida automáticamente
Artículo escrito por palaksinghal9903 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA