Table index/pk pour le verrouillage optimiste dans JPA

Quelle est la meilleure pratique pour définir des index de table pour les entités supportant le verrouillage optimiste? Il est certain que l'identifiant d'entité doit faire partie d'un index dans la base de données pour permettre des recherches rapides par id.Table index/pk pour le verrouillage optimiste dans JPA

Qu'en est-il de la colonne version? Est-ce logique de le faire partie d'un index? Que se passe-t-il si nous ne définissons pas la clé primaire DB, mais que nous créons un index composé de l'identifiant de l'entité + la colonne de la version?

Risque d'avoir deux lignes en DB avec le même identifiant d'entité? Dites deux transactions persistent deux entités avec le même id d'entité en parallèle?

Source

2013-01-03 Moose on the Loose

Votre question serpente un peu et me demande quel problème vous essayez vraiment de résoudre. Mais quel que soit le problème, la suppression des clés primaires devrait certainement *** PAS *** sur votre liste de solutions possibles. – Perception

Ma principale préoccupation est de savoir si le fait de ne pas avoir de clé primaire DB correspondant à l'identifiant de l'entité peut faire du tort lorsque le verrouillage optimiste est utilisé. Je pense que la réponse est oui. Say, deux threads tentent de conserver l'entité avec le même identifiant d'entité en parallèle. Même si elles exécutent find(), les deux peuvent ne pas trouver d'entrée dans db correspondant à l'identifiant d'entité et les deux vont essayer d'insérer des données dans DB. PK se serait gardé contre ce scénario. Par conséquent, c'est obligatoire. –

Ainsi, vous exécutez des insertions simultanées dans la base de données avec des clés primaires potentiellement conflictuelles? Vous devriez probablement redéfinir votre générateur de clé ou utiliser un identifiant auto-incrémenté. Dans tous les cas, votre base de données sérialisera les insertions et après que la première transaction réussie sera validée, toutes les suivantes avec le même identifiant échoueront. – Perception

Supposons que vous ayez une entité définie avec une colonne de version comme suit:

@Entity 
public class MyEntity implements Serializable {  

    @Id 
    @GeneratedValue 
    private Long id; 

    private String name; 

    @Version 
    private Long version; 

    //... 
}

sur la mise à jour, le champ annoté avec @Version sera incrémentée et ajouté à la clause WHERE, par exemple:

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

Comme vous pouvez le voir, la colonne version est utilisée dans la clause WHERE, mais il en va de même pour la colonne ID (qui a déjà un index car c'est la clé primaire), donc je ne pense pas que vous verriez beaucoup bénéficier d'addi ng un index à la colonne VERSION.

Source

2013-01-03 02:54:58

Table index/pk pour le verrouillage optimiste dans JPA

Répondre

Questions connexes