java - ¿Cuál es la diferencia entre PESSIMISTIC_READ y PESSIMISTIC_WRITE en JPA?
locking (4)
He leído el artículo Bloqueo y concurrencia en Java Persistence 2.0 y ejecuto la aplicación de muestra. Pero todavía no puedo darme cuenta de la diferencia entre PESSIMISTIC_READ y PESSIMISTIC_WRITE. Traté de modificar el código, y donde el código que usa PESSIMISTIC_READ y PESSIMISTIC_WRITE tendrá el mismo resultado que el sql se invocará con "para actualizar".
El PESSIMISTIC_READ adquiere un bloqueo compartido (de lectura) en el registro de la fila de la tabla asociada, mientras que PESSIMISTIC_WRITE adquiere un bloqueo exclusivo (escritura).
El bloqueo compartido bloquea cualquier otra solicitud simultánea de bloqueo exclusivo, pero permite que continúen otras solicitudes de bloqueo compartido.
El bloqueo exclusivo bloquea las solicitudes de bloqueo compartidas y exclusivas.
Lo que vale la pena mencionar es que, para Hibernate, si la base de datos no admite bloqueos compartidos (por ejemplo, Oracle), entonces una solicitud de bloqueo compartido ( PESSIMISTIC_READ ) simplemente obtendrá una solicitud de bloqueo exclusivo ( PESSIMISTIC_WRITE ).
Para obtener más información, consulte este artículo sobre bloqueos y este artículo sobre los tipos de bloqueo pesimista JPA .
La diferencia radica en el mecanismo de bloqueo.
PESSIMISTIC_READ bloqueo PESSIMISTIC_READ significa que las lecturas sucias y las lecturas no repetibles son imposibles cuando se tiene dicho bloqueo. Si se deben cambiar los datos, es necesario obtener el bloqueo PESSIMISTIC_WRITE
PESSIMISTIC_WRITE bloqueo PESSIMISTIC_WRITE garantiza que, además de las lecturas sucias y no repetibles, es imposible actualizar los datos sin obtener bloqueos adicionales (y posibles deadlocks mientras se espera el bloqueo exclusivo).
╔══════════════════════╦══════════════════════════╦══════════════════════════╗
║ LockModeType ║ PESSIMISTIC_READ ║ PESSIMISTIC_WRITE ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ type ║ SHARED LOCK ║ EXCLUSIVE LOCK ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ isReadOnly without ║ ║ ║
║ additional locks ║ YES ║ NO ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ dirty reads ║ NO ║ NO ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ non-repeatable reads ║ NO ║ NO ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ how to update data ║ obtain PESSIMISTIC_WRITE ║ ALLOWED ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ ║ no one holds ║ no one holds ║
║ how to obtain lock ║ PESSIMISTIC_WRITE ║ PESSIMISTIC_READ or ║
║ ║ ║ PESSIMISTIC_WRITE ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ ║ ║ when there is a high ║
║ ║ you want to ensure no ║ likelihood of deadlock or║
║ when to use ║ dirty or non-repeatable ║ update failure among ║
║ ║ reads are possible ║ concurrent updating ║
║ ║ ║ transactions ║
╚══════════════════════╩══════════════════════════╩══════════════════════════╝
Recursos:
La especificación permite que la implementación de JPA use un tipo diferente de bloqueo de base de datos para cada uno. La mayoría de las bases de datos solo tienen un tipo de bloqueo declarativo, por lo que en la mayoría de las implementaciones las dos son idénticas (no hay diferencia).
Uno es un bloqueo de lectura y el otro es un bloqueo de escritura, o durante una lectura o una actualización, respectivamente.
FTA:
PESSIMISTIC_READ. El administrador de la entidad bloquea la entidad tan pronto como una transacción la lea. El bloqueo se mantiene hasta que la transacción se complete. Este modo de bloqueo se utiliza cuando desea consultar datos utilizando semántica de lectura repetible. En otras palabras, quiere asegurarse de que los datos no se actualicen entre sucesivas lecturas. Este modo de bloqueo no impide que otras transacciones lean los datos.
PESSIMISTIC_WRITE. El administrador de la entidad bloquea la entidad tan pronto como una transacción la actualice. Este modo de bloqueo fuerza la serialización entre las transacciones que intentan actualizar los datos de la entidad. Este modo de bloqueo a menudo se usa cuando hay una alta probabilidad de falla de actualización entre las transacciones de actualización concurrentes.