El control de concurrencia optimista (en inglés Optimistic concurrency control o OCC) es un método de control de concurrencia que se aplica a sistemas transaccionales, tales como sistemas de gestión de bases de datos relacionales y memoria transaccional de software. El OCC asume que múltiples transacciones se pueden completar frecuentemente sin interferir entre sí. Mientras se ejecutan, las transacciones utilizan recursos de datos sin adquirir bloqueos en esos recursos. Antes de hacer el commit, cada transacción verifica que ninguna otra transacción ha modificado los datos que ha leído. Si la comprobación revela modificaciones en conflicto, la transacción que iba a hacer commit hace un rollback y se puede reiniciar.^[1]​ El control de concurrencia optimista fue propuesto por primera vez por H. T. Kung.^[2]​

El 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 coste de la gestión de bloqueos y sin tener transacciones esperando a que se borren los bloqueos de otras transacciones, dando lugar a un mayor rendimiento que otros métodos de control de concurrencia. Sin embargo, si la contención de recursos de datos es frecuente, el coste de reiniciar las transacciones repetidamente perjudica el rendimiento de manera significativa; comúnmente se piensa que otros métodos de control de concurrencia tienen un mejor rendimiento en estas condiciones. Sin embargo, los métodos basados en bloqueos ("pesimistas") también pueden ofrecer un rendimiento pobre porque los bloqueos pueden limitar drásticamente la concurrencia efectiva incluso cuando se evitan los deadlocks.

Más en concreto, las transacciones del OCC implican estas fases:

• Inicio: Grabar un timestamp que marca el inicio de la transacción.
• Modificar: Leer los valores de la base de datos y tentativamente escribir cambios.
• Validar: Comprobar si otras transacciones han modificado datos que esta transacción ha utilizado (leído o escrito). Esto incluye las transacciones que se han completado con posterioridad al tiempo de inicio de esta transacción y, opcionalmente, las transacciones que aún están activas en el momento de la validación.
• Commit/Rollback: Si no hay conflicto, hacer que todos los cambios surtan efecto. Si hay un conflicto, resolverlo, típicamente abortando la transacción, aunque otros sistemas de resolución son posibles. Se debe tener cuidado para evitar un bug TOCTTOU, 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 no sea factible para interfaces de usuarios web. Es común que un usuario empiece a editar un registro y, a continuación, salga sin seguir un enlace de "cancelar" o " cerrar sesión". Si se utilizan bloqueos, otros usuarios que intentan editar el mismo registro deben esperar hasta que el bloqueo del primer usuario termine.

HTTP proporciona una forma de OCC incorporada: El método GET devuelve un ETag para un recurso y PUTs posteriores utilizan el valor del ETag en las cabeceras If-Match ; mientras que el primer PUT tendrá éxito, el segundo no, ya que el valor de If-Match está basado en la primera versión del recurso.^[3]​

Algunos sistemas de gestión de bases de datos ofrecen OCC de forma nativa - sin necesidad de código de aplicación especial. Para otros, la aplicación puede implementar una capa de OCC fuera de la base de datos, y no tener que esperar o sobrescribir registros en silencio. En tales casos, el formulario incluye un campo oculto con el contenido del registro original, un timestamp, un número de secuencia, o un token opaco. Al enviar (submit), se compara con la base de datos. Si es diferente, se invoca el algoritmo de resolución de conflictos.

• Las páginas de edición de MediaWiki utilizan OCC.^[4]​
• Bugzilla usa OCC; los conflictos de edición son llamados "mid-air collisions".^[5]​
• El framework Ruby on Rails tiene una API para OCC.^[6]​
• El framework Grails utiliza OCC en sus convenciones predeterminadas.^[7]​
• El motor de bases de datos GT.M utiliza OCC para la gestión de transacciones^[8]​ (incluso las actualizaciones individuales son tratadas como mini-transacciones).
• Entity Framework de Microsoft (incluyendo Code-First) tiene soporte incorporado para OCC basado en un valor de timestamp binario.^[9]​
• Mimer SQL es un DBMS que sólo implementa el control de concurrencia optimista.^[10]​
• El almacén de datos de Google App Engine utiliza OCC.^[11]​
• El motor de búsqueda ElasticSearch soporta OCC a través del atributo de versión.^[12]​
• El esquema de gestión de transacciones del sistema de gestión de base de datos orientado a columnas MonetDB se basa en OCC.^[13]​
• La mayoría de las implementaciones de memoria transaccional de software utilizan el bloqueo optimista.

• Kung, H. T.; John T. Robinson (junio de 1981). «On optimistic methods for concurrency control». ACM Transactions on Database Systems 6 (2): 213-226. doi:10.1145/319566.319567.  La referencia utiliza el parámetro obsoleto |coautores= (ayuda)
• Enterprise JavaBeans, 3.0, By Bill Burke, Richard Monson-Haefel, Chapter 16. Transactions, Section 16.3.5. Optimistic Locking, Publisher: O'Reilly, Pub Date: May 16, 2006,Print ISBN 0-596-00978-X,
• Hollmann, Andreas (May 2009). «Multi-Isolation: Virtues and Limitations». Multi-Isolation (what is between pessimistic and optimistic locking). 01069 Gutzkovstr. 30/F301.2, Dresden: Happy-Guys Software GbR. p. 8. Consultado el 16 de mayo de 2013.  (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).