He leído el artículo Locking and Concurrency in 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".¿Cuál es la diferencia entre PESSIMISTIC_READ y PESSIMISTIC_WRITE en JPA?
Uno es un bloqueo de lectura y el otro es un bloqueo de escritura, o durante una lectura o una actualización, respectivamente.
TLC:
PESSIMISTIC_READ. El administrador de entidad bloquea la entidad tan pronto como una transacción la lea. El bloqueo es retenido hasta que se complete la transacción. Este modo de bloqueo se usa cuando desea para consultar datos utilizando la semántica repetible de lectura . En otras palabras, desea para asegurarse de que los datos no estén actualizados entre sucesivas lecturas. Este modo de bloqueo no bloquea otras transacciones al leer los datos.
PESSIMISTIC_WRITE. El administrador de 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 suele ser cuando existe una alta probabilidad de de error de actualización entre las transacciones de actualización simultáneas .
La especificación permite que la implementación de JPA utilice 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).
La diferencia radica en el mecanismo de bloqueo.
PESSIMISTIC_READ bloqueo significa que las lecturas sucias y las lecturas no repetibles son imposibles cuando se tiene dicho bloqueo. Si los datos se deben cambiar se requiere para obtener PESSIMISTIC_WRITE bloqueo
PESSIMISTIC_WRITE garantías de bloqueo que además lee sucia y no repetibles son imposibles puede actualizar los datos sin obtener cerraduras adicionales (y posible deadlocks a la espera de 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:
El PESSIMISTIC_READ adquiere un bloqueo compartido (lectura) en el registro de fila de la tabla asociada, mientras que el PESSIMISTIC_WRITE se establece un bloqueo (escritura) exclusiva.
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), una solicitud de bloqueo compartido (PESSIMISTIC_READ) simplemente obtendrá una solicitud de bloqueo exclusivo (PESSIMISTIC_WRITE). Para obtener más información, consulte this article about locks y this article about JPA pessimistic lock types.
gracias, vi la descripción, pero todavía me confunde. Cuando uso PESSIMISTIC_READ y PESSIMISTIC_WRITE, siempre obtiene el mismo resultado en "show sql" y en el resultado de la ejecución. – paka
¡Buena explicación !. ¿Podría agregar algún código de muestra para demostrar? – Velu
@paka: la especificación JPA dice: "Está permitido que una implementación use LockModeType.PESSIMISTIC_WRITE donde se solicitó LockModeType.PESSIMISTIC_READ, pero no al revés". ver [esta respuesta] (http://stackoverflow.com/a/33081311/3994580) para detalles – DaniEll