Java - JPA - @Version Anotación

Question

¿Cómo funciona la anotación @Version en JPA?

He encontrado varias respuestas cuyo extracto es el siguiente:

APP utiliza un campo de versión en sus entidades para detectar modificaciones concurrentes para el mismo registro del almacén de datos. Cuando el tiempo de ejecución de JPA detecta un intento de modificar al mismo tiempo el mismo registro, arroja una excepción a la transacción que intenta cometer el último.

Pero todavía no estoy seguro de cómo funciona.

---

también a partir de las siguientes líneas:

usted debe considerar campos de versión inmutable. Cambiar el valor del campo tiene resultados indefinidos.

¿Significa que deberíamos declarar nuestro campo de versión como final?

Answer 1

Pero todavía no estoy seguro de cómo funciona?

Digamos que una entidad MyEntity tiene una anotada version propiedad:

@Entity 
public class MyEntity implements Serializable {  

    @Id 
    @GeneratedValue 
    private Long id; 

    private String name; 

    @Version 
    private Long version; 

    //... 
} 

En la actualización, el campo anotado con @Version se incrementará y se añade a la cláusula WHERE, algo como esto:

UPDATE MYENTITY SET ..., VERSION = VERSION + 1 WHERE ((ID = ?) AND (VERSION = ?)) 

Si la cláusula WHERE no coincide con un registro (porque la misma entidad ya ha sido actualizada por otro hilo), luego el proveedor de persistencia lanzará un OptimisticLockException.

¿Quiere decir que debemos declarar nuestro campo de versión como definitiva

No, pero se podía considerar la posibilidad de la incubadora protegida como que no se supone llamarlo.

Answer 2

Cada vez que se actualiza una entidad en la base de datos, el campo de versión se incrementará en uno. Cada operación que actualice la entidad en la base de datos tendrá como anexo WHERE version = VERSION_THAT_WAS_LOADED_FROM_DATABASE a su consulta.

En comprobación de filas afectadas de la operación del marco de la APP puede asegurarse de que no hubo modificación concurrente entre la carga y la persistencia de su entidad porque la consulta no encontraría su entidad en la base de datos cuando es el número de versión se ha incrementado entre la carga y persistir .

Answer 3

Versión utilizada para garantizar que solo se realice una actualización a la vez. El proveedor de JPA verificará la versión, si la versión esperada ya ha aumentado, entonces otra persona ya actualizará la entidad para que se genere una excepción.

Así que actualizar el valor de la entidad sería más seguro, más optimista.

Si el valor cambia con frecuencia, puede considerar no utilizar el campo de versión. Para un ejemplo "una entidad que tiene campo de contador, que se incrementará cada vez que una página web accesible"

Answer 4

Aunque respuesta @Pascal es perfectamente válido, desde mi experiencia puedo encontrar el código de abajo útiles para llevar a cabo el bloqueo optimista:

@Entity 
public class MyEntity implements Serializable {  
    // ... 

    @Version 
    @Column(name = "optlock", columnDefinition = "integer DEFAULT 0", nullable = false) 
    private long version = 0L; 

    // ... 
} 

¿Por qué? Porque:

1. Bloqueo optimista no va a funcionar si el campo anotado con @Version accidentalmente se configura null.
2. Como este campo especial no es necesariamente una versión comercial del objeto, para evitar un error, prefiero llamar a este campo como optlock en lugar de version.

Primer punto no importa si la aplicación utiliza solamente APP para insertar datos en la base de datos, como proveedor JPA hará cumplir 0 para @version campo durante la creación. Pero casi siempre las sentencias SQL simples también están en uso (al menos durante las pruebas de unidad/integración).

Answer 5

Solo agrego un poco más de información.

JPA gestiona la versión bajo el capó para usted, sin embargo, no lo hace al actualizar su registro a través de JPAUpdateClause(), en tales casos debe agregar manualmente el incremento de la versión a la consulta.

Pedro