Control de concurrencia optimista

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

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.

Fases del OCC[editar]

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.

Uso en la Web[editar]

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.

Ejemplos[editar]

Referencias[editar]

  1. Johnson, Rohit (2003). «Common Data Access Issues». Expert One-on-One J2EE Design and Development. Wrox Press. ISBN 0-7645-4385-7. 
  2. Kung, H.T. (1981). «On Optimistic Methods for Concurrency Control». ACM Transactions on Database Systems. 
  3. «Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout». W3C Note (10 May 1999).
  4. Help:Edit conflict
  5. «Bugzilla: FAQ: Administrative Questions». MozillaWiki (11 April 2012).
  6. «Module ActiveRecord::Locking». Rails Framework Documentation.
  7. «Object Relational Mapping (GORM)». Grails Framework Documentation.
  8. «Transaction Processing». GT.M Programmers Guide UNIX Edition.
  9. «Tip 19 – How to use Optimistic Concurrency with the Entity Framework». MSDN Blogs (19 May 2009).
    • Most revision control systems support the "merge" model for concurrency, which is OCC.
  10. «Transaction Concurrency - Optimistic Concurrency Control». Mimer Developers - Features (26 February 2010).
  11. «The Datastore». What Is Google App Engine? (27 August 2010).
  12. «elasticsearch - guide - Index API». ElasticSearch Guide (22 March 2012).
  13. «Transactions - MonetDB» (16 January 2013).

Enlaces externos[editar]

  • «On optimistic methods for concurrency control». ACM Transactions on Database Systems 6 (2):  pp. 213–226. June 1981. doi:10.1145/319566.319567. 
  • 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» (PDF). Multi-Isolation (what is between pessimistic and optimistic locking). 01069 Gutzkovstr. 30/F301.2, Dresden: Happy-Guys Software GbR. pp. 8.