JPA: ¿Cómo funciona el bloqueo de lectura?

Question

Estoy tratando de entender cuál es el efecto de llamar a EntityManager.lock (entidad, LockModeType.READ). La documentación de API me suena muy confusa.

Si tengo hilos concurrentes y el hilo 1 bloquea las llamadas (entidad, LockModeType.READ), ¿puede el hilo 2 aún leer y escribir la entidad?

Lo que he aprendido hasta ahora:

El tipo de bloqueo de lectura en JPA1 es la misma que en OPTIMISTA JPA2. Si se establece dicho bloqueo, EntityManager verifica el atributo de versión antes de comprometer la transacción, pero no la actualiza. Encontré una explicación para el modo de bloqueo OPTIMISTIC: Link. Buscar OPTIMISTIC (READ) LockMode Ejemplo. Tan pronto como entiendo esto, establecer un bloqueo de lectura en el Hilo 1 no tiene ningún efecto en Hilos 2 ... n. Todos los demás hilos aún pueden leer y escribir la entidad. Pero cuando la transacción en el Hilo 1 se compromete y otro Hilo ha actualizado la entidad, la transacción en el Hilo 1 se revierte.

¿Entiendo esto correcto?

Answer 1

Lee está en desuso Curently todos modos, pero sólo para su comprensión:

bloqueo

A LEER asegurará que el estado del objeto no cambia de cometer, porque el bloqueo READ permite otras operaciones para actualizar o suprimir entonces si El subproceso 1 hace algunos cambios y luego lo confirma primero comprueba el estado (la versión) de la entidad si comprueba, está confirmado, si no no está permitido,

tan básicamente su comprensión es correcta.

también hay OPTIMISTIC_READ que es la forma moderna de usarlo (también hay _WRITE).

ACTUALIZACIÓN

Muy bien, este article me ayudó mucho en la comprensión espero que esto ayude.