Annotation Java - JPA - @Version

Comment fonctionne l' @Versionannotation dans JPA?

J'ai trouvé diverses réponses dont l'extrait est le suivant:

JPA utilise un champ de version dans vos entités pour détecter les modifications simultanées du même enregistrement de banque de données. Lorsque l'environnement d'exécution JPA détecte une tentative de modification simultanée du même enregistrement, il lève une exception à la transaction qui tente de valider en dernier.

Mais je ne sais toujours pas comment cela fonctionne.

Aussi à partir des lignes suivantes:

Vous devez considérer les champs de version immuables. La modification de la valeur du champ a des résultats non définis.

Cela signifie-t-il que nous devrions déclarer notre champ de version comme final?

Mais je ne sais toujours pas comment cela fonctionne?

Disons qu'une entité MyEntitya une versionpropriété annotée :

@Entity
public class MyEntity implements Serializable {    

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @Version
    private Long version;

    //...
}

Lors de la mise à jour, le champ annoté avec @Versionsera incrémenté et ajouté à la WHEREclause, quelque chose comme ceci:

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

Si la WHEREclause ne correspond pas à un enregistrement (car la même entité a déjà été mise à jour par un autre thread), le fournisseur de persistance lèvera un OptimisticLockException.

Cela signifie-t-il que nous devons déclarer notre champ de version comme final

Non, mais vous pourriez envisager de protéger le passeur car vous n'êtes pas censé l'appeler.

Bien que la réponse @Pascal soit parfaitement valide, d'après mon expérience, je trouve le code ci-dessous utile pour réaliser un verrouillage optimiste:

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

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

    // ...
}

Pourquoi? Car:

1. Le verrouillage optimiste ne fonctionnera pas si le champ annoté avec @Versionest accidentellement défini sur null.
2. Comme ce champ spécial n'est pas nécessairement une version commerciale de l'objet, pour éviter une erreur, je préfère nommer ce champ à quelque chose comme optlockplutôt que version.

Premier point n'a pas d' importance si application utilise uniquement JPA pour insérer des données dans la base de données, en tant que fournisseur JPA appliquera 0pour le @versionterrain au moment de la création. Mais presque toujours des instructions SQL simples sont également utilisées (au moins pendant les tests unitaires et d'intégration).

Chaque fois qu'une entité est mise à jour dans la base de données, le champ de version est augmenté de un. Chaque opération qui met à jour l'entité dans la base de données sera ajoutée WHERE version = VERSION_THAT_WAS_LOADED_FROM_DATABASEà sa requête.

En vérifiant les lignes affectées de votre opération, le framework jpa peut s'assurer qu'il n'y a pas eu de modification simultanée entre le chargement et la persistance de votre entité car la requête ne trouverait pas votre entité dans la base de données lorsque son numéro de version a été augmenté entre le chargement et la persistance.

Version utilisée pour garantir qu'une seule mise à jour à la fois. Le fournisseur JPA vérifiera la version, si la version attendue augmente déjà, quelqu'un d'autre met déjà à jour l'entité, donc une exception sera levée.

La mise à jour de la valeur de l'entité serait donc plus sûre, plus optimiste.

Si la valeur change fréquemment, vous pouvez envisager de ne pas utiliser le champ de version. Pour un exemple "une entité qui a un champ de compteur, qui augmentera chaque fois qu'une page Web accédera"

Juste en ajoutant un peu plus d'informations.

JPA gère la version sous le capot pour vous, mais il ne le fait pas lorsque vous mettez à jour votre enregistrement via JPAUpdateClause, dans de tels cas, vous devez ajouter manuellement l'incrément de version à la requête.

Il en va de même pour la mise à jour via JPQL, c'est-à-dire pas une simple modification de l'entité, mais une commande de mise à jour de la base de données même si cela est fait par hibernate

Pedro