Control de concurrencia optimista

Método de control de concurrencia

El control de concurrencia optimista ( OCC ), también conocido como bloqueo optimista , es un método de control de concurrencia sin bloqueo que se aplica a sistemas transaccionales como sistemas de gestión de bases de datos relacionales y memoria transaccional de software . La OCC supone que con frecuencia se pueden completar múltiples transacciones sin interferir entre sí. Mientras se ejecutan, las transacciones utilizan recursos de datos sin adquirir bloqueos sobre esos recursos. Antes de confirmar, cada transacción verifica que ninguna otra transacción haya modificado los datos que ha leído. Si la verificación revela modificaciones contradictorias, la transacción comprometida se revierte y se puede reiniciar. ^[1] El control de concurrencia optimista fue propuesto por primera vez en 1979 por HT Kung y John T. Robinson. ^[2]

OCC se utiliza generalmente en entornos con baja contención de datos . Cuando los conflictos son poco frecuentes, las transacciones se pueden completar sin el gasto de administrar bloqueos y sin tener que esperar a que se eliminen los bloqueos de otras transacciones, lo que genera un mayor rendimiento que otros métodos de control de concurrencia. Sin embargo, si la contienda por los recursos de datos es frecuente, el costo de reiniciar repetidamente las transacciones perjudica significativamente el rendimiento, en cuyo caso otros métodos de control de concurrencia pueden ser más adecuados. Sin embargo, los métodos basados ​​en bloqueo ("pesimistas") también pueden ofrecer un rendimiento deficiente porque el bloqueo puede limitar drásticamente la concurrencia efectiva incluso cuando se evitan los interbloqueos.

Fases del control de concurrencia optimista

Las transacciones de control de concurrencia optimista implican estas fases: ^[2]

• Inicio : registra una marca de tiempo que marca el inicio de la transacción.
• Modificar : lee los valores de la base de datos y escribe cambios tentativamente.
• Validar : Verifique si otras transacciones han modificado datos que esta transacción ha utilizado (leídos o escritos). Esto incluye transacciones que se completaron después de la hora de inicio de esta transacción y, opcionalmente, transacciones que todavía están activas en el momento de la validación.
• Confirmar/Revertir : si no hay conflicto, haga que todos los cambios surtan efecto. Si hay un conflicto, resuélvalo, normalmente cancelando la transacción, aunque son posibles otros esquemas de resolución. Se debe tener cuidado para evitar un error entre el tiempo de verificación y el tiempo de uso , especialmente si esta fase y la anterior no se realizan como una única operación atómica .

Uso web

La naturaleza sin estado de HTTP hace que el bloqueo sea inviable para las interfaces de usuario web. Es común que un usuario comience a editar un registro y luego lo abandone sin seguir el enlace "cancelar" o "cerrar sesión". Si se utiliza el bloqueo, otros usuarios que intenten editar el mismo registro deben esperar hasta que expire el tiempo de bloqueo del primer usuario.

HTTP proporciona una forma de OCC integrada. La respuesta a una solicitud GET inicial puede incluir una ETag para que las solicitudes PUT posteriores la utilicen en el encabezado If-Match. Cualquier solicitud PUT con una ETag desactualizada en el encabezado If-Match puede rechazarse. ^[3]

Algunos sistemas de gestión de bases de datos ofrecen OCC de forma nativa, sin necesidad de un código de aplicación especial. Para otros, la aplicación puede implementar una capa OCC fuera de la base de datos y evitar esperar o sobrescribir registros silenciosamente. En tales casos, el formulario puede incluir un campo oculto con el contenido original del registro, una marca de tiempo, un número de secuencia o un token opaco. Al enviarlo, esto se compara con la base de datos. Si difiere, se invoca el algoritmo de resolución de conflictos.

Ejemplos

• Las páginas de edición de MediaWiki utilizan OCC. ^[4]
• Bugzilla usa OCC; Los conflictos de edición se denominan "colisiones en el aire". ^[5]
• El marco Ruby on Rails tiene una API para OCC. ^[6]
• El marco de Grails utiliza OCC en sus convenciones predeterminadas. ^[7]
• El motor de base de datos GT.M utiliza OCC para gestionar transacciones ^[8] (incluso las actualizaciones individuales se tratan como mini-transacciones).
• Entity Framework de Microsoft (incluido Code-First) tiene soporte integrado para OCC basado en un valor de marca de tiempo binario. ^[9]
• La mayoría de los sistemas de control de revisiones admiten el modelo de "fusión" para la concurrencia, que es OCC. ^{[ cita necesaria ]}
• Mimer SQL es un DBMS que solo implementa un control de concurrencia optimista. ^[10]
• El almacén de datos de Google App Engine utiliza OCC. ^[11]
• El motor de búsqueda Apache Solr admite OCC a través del campo _versión_. ^[12]
• El motor de búsqueda Elasticsearch actualiza sus documentos vía OCC. A cada versión de un documento se le asigna un número de secuencia y las versiones más recientes reciben números de secuencia más altos. Como los cambios en un documento llegan de forma asincrónica, el software puede usar el número de secuencia para evitar reemplazar una versión más nueva por una anterior. ^[13]
• CouchDB implementa OCC mediante revisiones de documentos. ^[14]
• El esquema de gestión de transacciones del sistema de gestión de bases de datos orientado a columnas MonetDB se basa en OCC. ^[15]
• La mayoría de las implementaciones de memoria transaccional de software utilizan OCC. ^{[ cita necesaria ]}
• Redis proporciona OCC a través del comando WATCH. ^[dieciséis]
• Firebird utiliza una arquitectura multigeneracional como implementación de OCC para la gestión de datos. ^{[ cita necesaria ]}
• DynamoDB utiliza actualización condicional como implementación de OCC. ^[17]
• Kubernetes utiliza OCC al actualizar recursos. ^[18]
• YugabyteDB es una base de datos nativa de la nube que utiliza principalmente OCC. ^[19]
• Firestore es una base de datos NoSQL de Firebase que utiliza OCC en sus transacciones.

Ver también

• Bloqueo de mensajes del servidor#Bloqueo oportunista

Referencias

1. Johnson, Rohit (2003). "Problemas comunes de acceso a datos". Diseño y desarrollo experto de J2EE uno a uno . Prensa Wrox. ISBN 978-0-7645-4385-2. Archivado desde el original el 8 de octubre de 2011.
2. HT Kung, JT Robinson (1981). "Sobre métodos optimistas para el control de la concurrencia" (PDF) . Transacciones ACM en sistemas de bases de datos. Archivado (PDF) desde el original el 31 de agosto de 2019.
3. "Edición de la Web: detección del problema de actualización perdida mediante el pago sin reservas". Nota del W3C . 10 de mayo de 1999.
4. Ayuda:Editar conflicto
5. "Bugzilla: Preguntas frecuentes: Preguntas administrativas". MozillaWiki . 11 de abril de 2012.
6. "Módulo ActiveRecord::Bloqueo". Documentación del marco de Rails .
7. "Mapeo relacional de objetos (GORM)". Documentación del marco de Grails . Archivado desde el original el 15 de agosto de 2014.
8. "Procesamiento de transacciones". Guía de programadores de GT.M Edición UNIX .
9. "Consejo 19: Cómo utilizar la simultaneidad optimista con Entity Framework". Blogs de MSDN . 19 de mayo de 2009.
10. "Simultaneidad de transacciones: control de simultaneidad optimista". Desarrolladores Mimer: características . Consultado el 22 de diciembre de 2023 .
11. "El almacén de datos". ¿Qué es el motor de aplicaciones de Google? . 27 de agosto de 2010.
12. "Actualización de partes de documentos" . Consultado el 28 de junio de 2018 .
13. "Control de concurrencia optimista". Elástico . Consultado el 5 de febrero de 2024 .
14. "Descripción técnica". Documentación de Apache CouchDB . Consultado el 6 de febrero de 2024 .
15. "Transacciones - MonetDB". 16 de enero de 2013.
16. "Transacciones en Redis".
17. "Trabajar con elementos y atributos: escrituras condicionales" . Consultado el 2 de noviembre de 2020 .
18. "Descripción general de API: operaciones de recursos" . Consultado el 3 de noviembre de 2020 .
19. Yugabyte, equipo. "Bloqueo explícito | Documentos de YugabyteDB". docs.yugabyte.com . Consultado el 4 de enero de 2022 .

enlaces externos

• Kung, HT; John T. Robinson (junio de 1981). "Sobre métodos optimistas para el control de la concurrencia". Transacciones ACM en sistemas de bases de datos . 6 (2): 213–226. CiteSeerX  10.1.1.101.8988 . doi :10.1145/319566.319567. S2CID  61600099.
• Enterprise JavaBeans, 3.0, por Bill Burke, Richard Monson-Haefel, Capítulo 16. Transacciones, Sección 16.3.5. Bloqueo optimista, Editorial: O'Reilly, Fecha de publicación: 16 de mayo de 2006, ISBN de impresión 0-596-00978-X , 
• Hollmann, Andreas (mayo de 2009). "Aislamiento múltiple: virtudes y limitaciones" (PDF) . Multiaislamiento (qué hay entre bloqueo pesimista y optimista) . 01069 Gutzkovstr. 30/F301.2, Dresde: Happy-Guys Software GbR. pag. 8 . Consultado el 16 de mayo de 2013 .{{cite conference}}: Mantenimiento CS1: ubicación ( enlace )^{[ enlace muerto permanente ]}