Técnicas de bloqueo sobre Base de Datos: Bloqueo Pesimista y Bloqueo Optimista

Recupero esto que tenía escrito por aquí, que me lo han pedido :)

Bloqueo pesimista

El bloqueo pesimista es la técnica por la cual los datos son bloqueados previos a su modificación para evitar que nadie los modifique. Una vez que los datos a actualizar han sido bloqueados la aplicación puede acometer los cambios, con commit o rollback, en ese caso el bloqueo es automáticamente eliminado. Si alguien intenta adquirir un bloqueo de los mismos datos durante el proceso será obligado a esperar hasta que la primera transacción finalice.

Esta técnica es muy simple pero tiene dos problemas fundamentales:

Ø Bloqueo: un usuario selecciona un registro para actualizar, y entonces abandona la operación. Todos los usuarios que necesitan actualizar ese registro tienen que esperar hasta que se complete la transacción, o hasta que se mate y finalice el bloqueo.

Ø Deadlock: Si los usuarios A y B están ambos actualizando la base de datos a la vez y A bloqueo un registro e intenta adquirir un bloqueo mantenido por B, que a su vez está esperando a adquirir un bloqueo mantenido por A ambas transacciones quedarían en espera indefinidamente, dando lugar a un Deadlock.

En general los Sistemas RDBMS ofrecen cláusulas para este bloqueo. Oracle soporta bloqueo pesimista a nivel de fila. La sentencia estándar para el bloqueo es SELECT FOR UPDATE que hace que todas las sentencias UPDATE o SELECT FOR UPDATE de otras conexiones se bloqueen hasta que un commit, rollback o deadlock se produzca. Se produce un deadlock cuando un usuario que tiene la fila A bloqueada intenta bloquear la fila B, mientras que otro usuario tiene la fila B bloqueada e intenta bloquear la A. En este caso Oracle deshabilita uno de los bloqueos del usuario permitiendo al otro usuario bloquear ambas filas.

Oracle además tiene el bloqueo SELECT FOR UPDATE NO WAIT, de modo que Oracle causará una excepción cuando una fila bloqueada es seleccionada. Esto puede ser útil si no se quiere bloquear un usuario para un tiempo indefinido.

Bloqueo optimista con control de concurrencia

El bloqueo optimista no bloquea los registros que se van a actualizar y asume que los datos que están siendo actualizados no van a cambiar desde que se han leído. Puesto que en nuestro caso no se puede asumir esto es necesario un control de la concurrencia, de esta manera el bloqueo optimista con control de concurrencia asegura que los datos que están siendo escritos son consistentes con los leídos en primera instancia, es decir que ninguna otra transacción ha actualizado los datos después de la lectura. El procedimiento para asegurar la consistencia es muy sencillo: se leerá un valor junto al registro, se actualizará ese valor a la BD cuando el registro es actualizado.

Existen varios mecanismos asegurar el control de la concurrencia, el más común es el uso de un timestamp modificado. Este mecanismo sólo ofrece una resolución de un segundo.

Tipo

V

Descripción

Bloqueo pesimista o No todas las Bases de Datos lo soportan y cada una lo soporta de una manera

o Previene a los usuarios y aplicaciones de leer datos que están siendo modificados

o Los usuarios se enteran inmediatamente si no pueden acceder a una fila

o Es fácil de usar

o No todas las Bases de Datos lo soportan y cada una lo soporta de una manera.

o Necesita tener abierta la transacción, el bloqueo sólo es efectivo si la transacción está abierta.

o Mengua la escalabilidad.

o Utiliza recursos extra en la base de datos.

o Impide a otros usuarios de tener acceso de lectura a los datos.

o Puede producir deadlocks.

o Puede producir excesivos bloqueos.

Bloqueo optimista con control de concurrencia o Lo soportan todas las bases de datos

o Es fácil de usar

o No consume recursos extra en la BD.

o No crea bloqueos ni deadlocks.

o Es necesario crear triggers en la BD.

o Requiere un pequeño trabajo extra.

o Retrasa las actualizaciones.

o Todas las aplicaciones que actualizan una base de datos deben conocer el mecanismo de consistencia.

Bloqueo y Motores ORM

Hibernate, y en general los motores de persistencia, y por supuesto JPA soportan el bloqueo optimista simplificando su uso. Algunos motores como Hibernate o JPA 2 soportan incluso el bloqueo pesimista.

En este post hay un artículo sobre cómo gestiona JPA 2 la concurrencia.

Bloqueo optimista:

Bloqueo pesimista:

About these ads
Publicado en Tutoriales. 1 Comment »

Una respuesta to “Técnicas de bloqueo sobre Base de Datos: Bloqueo Pesimista y Bloqueo Optimista”

  1. RE: Como puedo obtener ultimo id insertado evitando la concurrencia. - Foros - JavaDabbaDoo Says:

    [...] (Desmarcar) 22/05/11 22:08 en respuesta a Carlos Cesar peñate. Hola Carlos,En el post Técnicas de bloqueo sobre Base de Datos: Bloqueo Pesimista y Bloqueo Optimista hay un vínculo hacia el post JPA 2.0 Concurrency and locking. Este post lo puedes encontrar [...]


Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 475 seguidores

A %d blogueros les gusta esto: