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:
Un poco de Java 
[…] (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 […]