Solución:
No hay directo relación entre @Transactional y @LockMode anotaciones.
@Transactional se utiliza para marcar los límites explícitos de una transacción RESOURCE_LOCAL o JTA. La razón por la que lo necesita es que cada declaración de la base de datos se ejecuta en un contexto transaccional y, si no establece los límites de la transacción, obtendrá una transacción por declaración o confirmación automática.
Por otra parte, @LockModeType es para configurar opciones de bloqueo explícitas. Si no lo configura, se utilizarán los mecanismos de bloqueo implícitos:
- Los bloqueos implícitos se adquieren en cada fila modificada en los motores de base de datos 2PL y MVCC. Los bloqueos compartidos se adquieren en registros de lectura en motores 2PL si utiliza Lectura repetible en serializable.
- Si definiste un
@Versionpropiedad, la implícito Se utilizará un mecanismo de bloqueo optimista.
Entonces, @LockModeType es para configurar las opciones de bloqueo explícitamente, y puede tener las siguientes opciones:
LockModeType.PESSIMISTIC_READLockModeType.PESSIMISTIC_WRITE
los PESSIMISTIC los modos de bloqueo siempre adquirirán un bloqueo de base de datos en la fila de la tabla que está asociada con la entidad bloqueada.
También hay estrategias de bloqueo optimistas explícitas:
LockModeType.OPTIMISTICLockModeType.OPTIMISTIC_FORCE_INCREMENTLockModeType.PESSIMISTIC_FORCE_INCREMENT
los OPTIMISTIC los modos de bloqueo están destinados a brindarle una forma de aumentar una versión de entidad incluso si la entidad no ha cambiado en el contexto de persistencia que se está ejecutando actualmente. Este es un mecanismo muy útil cuando necesita coordinar varias entidades secundarias utilizando su versión de entidad principal.
Hay muchos ejemplos en los enlaces que proporcioné en esta respuesta, así que tómese su tiempo, léalos todos y comprenderá todos estos conceptos con mayor detalle.
Muelles @Transactional y de Hibernate LockMode la clase es diferente.
Gestión de transacciones de primavera
@Transactional es una anotación de Spring para la gestión de transacciones declarativas, es decir, que define qué sentencias SQL se ejecutan juntas dentro de una transacción de base de datos. Utilizando el readOnly El atributo permite a Spring lanzar una excepción si intenta insertar filas dentro de una transacción de solo lectura, por ejemplo.
Sin embargo, con respecto al bloqueo, lo más probable es que utilice una lectura / escritura (readOnly = false) transacción, porque intentará modificar los datos.
Bloqueo pesimista
Hibernar LockMode se utiliza para bloqueo pesimista, p. ej. LockMode.UPGRADE en realidad ejecuta un SELECT...FOR UPDATE declaración, y bloquea la fila en la base de datos correspondiente a la entidad.
El bloqueo pesimista supone que las transacciones simultáneas entrarán en conflicto entre sí y requiere que los recursos se bloqueen después de que se lean y solo se desbloqueen después de que la aplicación haya terminado de usar los datos.
Bloqueo optimista
El control de concurrencia optimista en Hibernate generalmente usa una columna de versión o marca de tiempo en la base de datos. La idea aquí es que si varias transacciones intentan modificar una fila al mismo tiempo, todas menos la primera transacción comprometida detectarán que el número de versión ha cambiado y realizarán una reversión.
El bloqueo optimista supone que se pueden completar varias transacciones sin que se afecten entre sí y que, por lo tanto, las transacciones pueden continuar sin bloquear los recursos de datos a los que afectan. Antes de comprometerse, cada transacción verifica que ninguna otra transacción haya modificado sus datos. Si la comprobación revela modificaciones conflictivas, la transacción de confirmación se revierte.
Las citas anteriores son de: https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html