Control de concurrencia optimista

El control de concurrencia optimista ( OCC ), también conocido como bloqueo optimista , es un método de control de concurrencia sin bloqueo aplicado a sistemas transaccionales como los sistemas de gestión de bases de datos relacionales y la memoria transaccional de software . OCC supone que varias transacciones pueden completarse con frecuencia sin interferir entre sí. Mientras se ejecutan, las transacciones utilizan recursos de datos sin adquirir bloqueos en esos recursos. Antes de confirmarse, cada transacción verifica que ninguna otra transacción haya modificado los datos que ha leído. Si la verificación revela modificaciones conflictivas, la transacción que confirma se revierte y puede reiniciarse. ^[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 poca contención de datos . Cuando los conflictos son poco frecuentes, las transacciones pueden completarse sin el gasto de gestionar bloqueos y sin que las transacciones tengan 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 contención de los recursos de datos es frecuente, el coste de reiniciar transacciones repetidamente perjudica el rendimiento de manera significativa, en cuyo caso otros métodos de control de concurrencia pueden ser más adecuados. Sin embargo, los métodos basados ​​en bloqueos ("pesimistas") también pueden ofrecer un rendimiento deficiente porque el bloqueo puede limitar drásticamente la concurrencia efectiva incluso cuando se evitan los bloqueos.

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

• Inicio : registra una marca de tiempo que marca el inicio de la transacción.
• Modificar : leer valores de la base de datos y escribir cambios tentativamente.
• Validar : comprueba 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 aún están activas en el momento de la validación.
• Confirmar/Revertir : si no hay ningún conflicto, hacer que todos los cambios surtan efecto. Si hay un conflicto, resolverlo, normalmente cancelando la transacción, aunque son posibles otros esquemas de resolución. Se debe tener cuidado para evitar un error de tiempo de verificación a tiempo de uso , en particular si esta fase y la anterior no se realizan como una única operación atómica .

La naturaleza sin estado de HTTP hace que el bloqueo no sea viable para las interfaces de usuario web. Es común que un usuario comience a editar un registro y luego lo abandone sin hacer clic en un vínculo de "cancelar" o "cerrar sesión". Si se utiliza el bloqueo, otros usuarios que intenten editar el mismo registro deben esperar hasta que se agote el tiempo de bloqueo del primer usuario.

HTTP proporciona una forma de OCC integrado. 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 ser rechazada. ^[3]

Algunos sistemas de gestión de bases de datos ofrecen OCC de forma nativa, sin necesidad de código de aplicación especial. En otros casos, la aplicación puede implementar una capa OCC fuera de la base de datos y evitar la espera o la sobrescritura silenciosa de registros. 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, se compara con la base de datos. Si difiere, se invoca el algoritmo de resolución de conflictos.

• Las páginas de edición de MediaWiki utilizan OCC. ^[4]
• Bugzilla utiliza 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 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 minitransacciones).
• 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 revisión admiten el modelo de "fusión" para concurrencia, que es OCC. ^{[ cita requerida ]}
• Mimer SQL es un DBMS que solo implementa 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 _version_. ^[12]
• El motor de búsqueda Elasticsearch actualiza sus documentos a través de OCC. A cada versión de un documento se le asigna un número de secuencia y las versiones más nuevas reciben números de secuencia más altos. A medida que los cambios a 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 antigua. ^[13]
• CouchDB implementa OCC a través de 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 requerida ]}
• Redis proporciona OCC a través del comando WATCH. ^[16]
• Firebird utiliza una arquitectura multigeneracional como implementación de OCC para la gestión de datos. ^{[ cita requerida ]}
• DynamoDB utiliza la actualización condicional como una 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.

• Bloqueo de mensajes del servidor#Bloqueo oportunista

• Kung, HT; John T. Robinson (junio de 1981). "Sobre métodos optimistas para el control de concurrencia". ACM Transactions on Database Systems . 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 impreso 0-596-00978-X , 
• Hollmann, Andreas (mayo de 2009). "Multi-Isolation: Virtudes and Limitations" (PDF) . Multi-Isolation (¿Qué hay entre el bloqueo pesimista y optimista?) . 01069 Gutzkovstr. 30/F301.2, Dresde: Happy-Guys Software GbR. p. 8 . Consultado el 16 de mayo de 2013 .{{cite conference}}: Mantenimiento de CS1: ubicación ( enlace )^{[ enlace muerto permanente ]}