Si te encuentras con algo que no comprendes puedes dejarnos un comentario y te ayudaremos rápidamente.
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 otro lado, @LockModeType es para establecer opciones de bloqueo explícitas. Si no lo establece, 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 usa lectura repetible en serializable.
- Si definió un
@Versionpropiedad, la implícito Se utilizará un mecanismo de bloqueo optimista.
Entonces, @LockModeType es para configurar las opciones de bloqueo explícitamentey 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 la versión de una 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 los de Hibernate LockMode clase son diferentes.
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 attribute permite que Spring lance 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 esté usando un comando de lectura/escritura (readOnly = false) transacción, porque intentará modificar los datos.
Bloqueo pesimista
de hibernación LockMode se utiliza para el bloqueo pesimista, por ejemplo LockMode.UPGRADE en realidad ejecuta un SELECT...FOR UPDATE y bloquea la fila en la base de datos correspondiente a la entidad.
El bloqueo pesimista supone que las transacciones concurrentes entrarán en conflicto entre sí y requiere que los recursos se bloqueen después de leerlos 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 excepto la primera transacción confirmada detectarán que el número de versión ha cambiado y realizarán una reversión.
El bloqueo optimista supone que varias transacciones pueden completarse sin afectarse 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 el cheque revela modificaciones en conflicto, 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