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 sistemas de gestión de bases de datos relacionales y memoria transaccional de software . OCC asume que múltiples transacciones pueden completarse frecuentemente sin interferir entre sí. Mientras se ejecutan, las transacciones utilizan recursos de datos sin adquirir bloqueos sobre dichos 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 se está confirmando 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 baja contención de datos . Cuando los conflictos son poco frecuentes, las transacciones pueden completarse sin el coste de gestionar bloqueos y sin que las transacciones tengan que esperar a que se liberen los bloqueos de otras transacciones, lo que resulta en un mayor rendimiento que otros métodos de control de concurrencia. Sin embargo, si la contención por los recursos de datos es frecuente, el coste de reiniciar repetidamente las transacciones perjudica significativamente el rendimiento, en cuyo caso otros métodos de control de concurrencia pueden ser más adecuados. No obstante, los métodos basados ​​en bloqueos ("pesimistas") también pueden ofrecer un rendimiento deficiente, ya que el bloqueo puede limitar drásticamente la concurrencia efectiva incluso cuando se evitan los interbloqueos.

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

• Inicio : Registre una marca de tiempo que indique el comienzo de la transacción.
• Modificar : Lee los valores de la base de datos y escribe los cambios de forma provisional.
• Validar : Comprueba si otras transacciones han modificado datos que esta transacción ha utilizado (leído o escrito). 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.
• Confirmación/Reversión : Si no hay conflicto, todos los cambios surten efecto. Si hay un conflicto, se resuelve, generalmente cancelando la transacción, aunque existen otros métodos de resolución. Es fundamental evitar errores de sincronización entre el momento de la verificación y el momento de la ejecución , especialmente 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 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 un enlace de "cancelar" o "cerrar sesión". Si se utiliza el bloqueo, otros usuarios que intenten editar el mismo registro deberán esperar hasta que expire el 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 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 de OCC fuera de la base de datos, evitando así la espera o la sobrescritura silenciosa de registros. En estos 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 enviar el formulario, este campo se compara con la base de datos. Si hay alguna diferencia, se activa el algoritmo de resolución de conflictos.

• 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 y 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 y limitaciones" (PDF) . Multi-Isolation (qué hay entre el bloqueo pesimista y el optimista) . 01069 Gutzkovstr. 30/F301.2, Dresde: Happy-Guys Software GbR. pág.  8. Consultado el 16 de mayo de 2013 .{{cite conference}}: CS1 mantenimiento: ubicación ( enlace )