JPA et optimiste modes de verrouillage

Ne soyez pas effrayés par cette longue réponse. Ce sujet n'est pas simple.

Par défaut JPA imposer
Lire commis niveau d'isolation si vous ne précisez pas de verrouillage (même comportement que l'utilisation de LockModeType.NONE).

Lire commis nécessite de la non-existence de la Sale lire phénomène. Simplement T1 ne peut voir les modifications apportées par T2 après T2 s'engage.

En utilisant le verrouillage optimiste en JPA s'élève le niveau d'isolation de
Repetable lit.

Si T1 lit des données au début et à la fin de la transaction, Repetable lit assure que T1 voit les mêmes données, même si T2 changé les données et commis dans le milieu de T1.

Et voici la partie la plus délicate. JPA réalise Repetable lit dans la manière la plus simple possible: par la prévention Non-Repetable lire phénomène. JPA n'est pas assez sophistiquée pour garder des instantanés de votre lit. Il empêche tout simplement de la deuxième lecture de passe en levant une exception (si les données ont changé depuis la première lecture).

Vous pouvez choisir entre deux optimiste options de verrouillage:

• LockModeType.OPTIMISTIC (LockModeType.READ en JPA 1.0)

• LockModeType.OPTIMISTIC_FORCE_INCREMENT (LockModeType.WRITE en JPA 1.0)

Quelle est la différence entre les deux?

Permettez-moi d'illustrer avec des exemples sur ce Person entité.

@Entity
public class Person {
    @Id int id;
    @Version int version;
    String name;
    String label;
    @OneToMany(mappedBy = "person", fetch = FetchType.EAGER)
    List<Car> cars;
    //getters & setters
}

Maintenant, nous supposons que nous avons une Personne nommée Jean stockées dans la base de données. Nous avons lu cette Personne en T1 mais changer son nom à Mike dans la deuxième transaction T2.

Sans verrouillage

Person person1 = em1.find(Person.class, id, LockModeType.NONE); //T1 reads Person("John")

Person person2 = em2.find(Person.class, id); //T2 reads Person("John")
person2.setName("Mike"); //Changing name to "Mike" within T2
em2.getTransaction().commit(); //T2 commits

System.out.println(em1.find(Person.class, id).getName()); //prints "John" - entity is already in Persistence cache
System.out.println(
  em1.createQuery("SELECT count(p) From Person p where p.name='John'")
    .getSingleResult()); //prints 0 - ups! don't know about any John (Non-repetable read)

Optimiste verrou en lecture

    Person person1 = em1.find(Person.class, id, LockModeType.OPTIMISTIC); //T1 reads Person("John")

    Person person2 = em2.find(Person.class, id); //T2 reads Person("John")
    person2.setName("Mike"); //Changing name to "Mike" within T2
    em2.getTransaction().commit(); //T2 commits

    System.out.println(
            em1.createQuery("SELECT count(p) From Person p where p.name='John'")
                    .getSingleResult()); //OptimisticLockException - The object [Person@2ac6f054] cannot be updated because it has changed or been deleted since it was last read. 

---

LockModeType.OPTIMISTIC_FORCE_INCREMENT est utilisé lorsque la modification est apportée à une autre entité (peut-être un non-propriétaire de la relation) et que nous voulons préserver l'intégrité.
Permettez-moi d'illustrer avec John acquisition d'une nouvelle voiture.

Optimiste verrou en lecture

Person john1 = em1.find(Person.class, id); //T1 reads Person("John")

Person john2 = em2.find(Person.class, id, LockModeType.OPTIMISTIC); //T2 reads Person("John")
//John gets a mercedes
Car mercedes = new Car();
mercedes.setPerson(john2);
em2.persist(mercedes);
john2.getCars().add(mercedes);
em2.getTransaction().commit(); //T2 commits

//T1 doesn't know about John's new car. john1 in stale state. We'll end up with wrong info about John.
if (john1.getCars().size() > 0) { 
    john1.setLabel("John has a car");
} else {
    john1.setLabel("John doesn't have a car");
}
em1.flush();

Optimiste verrou d'écriture

Person john1 = em1.find(Person.class, id); //T1 reads Person("John")
Person john2 = em2.find(Person.class, id, LockModeType.OPTIMISTIC_FORCE_INCREMENT); //T2 reads Person("John")
//John gets a mercedes
Car mercedes = new Car();
mercedes.setPerson(john2);
em2.persist(mercedes);
john2.getCars().add(mercedes);
em2.getTransaction().commit(); //T2 commits

//T1 doesn't know about John's new car. john1 in stale state. That's ok though because proper locking won't let us save wrong information about John.
if (john1.getCars().size() > 0) { 
    john1.setLabel("John has a car");
} else {
    john1.setLabel("John doesn't have a car");
}
em1.flush(); //OptimisticLockException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)

Bien qu'il y est une suite de remarques dans la JPA spec, Hibernate et EclipseLink se comporte très bien et ne l'utilisez pas.

Pour les versions d'objets, il est possible pour une mise en œuvre à utiliser LockMode-
Type.OPTIMISTIC_FORCE_INCREMENT où LockModeType.OPTIMISTE a été demandé,
mais pas vice-versa.