Java - JPA - adnotacja @Version

Jak działa @Versionadnotacja w JPA?

Znalazłem różne odpowiedzi, których wyciąg jest następujący:

JPA używa pola wersji w jednostkach, aby wykrywać współbieżne modyfikacje tego samego rekordu magazynu danych. Gdy środowisko wykonawcze JPA wykryje próbę równoczesnej modyfikacji tego samego rekordu, zgłasza wyjątek od transakcji, która próbuje zatwierdzić jako ostatnia.

Ale nadal nie jestem pewien, jak to działa.

Również z następujących linii:

Należy rozważyć niezmienność pól wersji. Zmiana wartości pola ma niezdefiniowane wyniki.

Czy to oznacza, że ​​powinniśmy zadeklarować nasze pole wersji jako final?

Ale nadal nie jestem pewien, jak to działa?

Powiedzmy, że encja MyEntityma opisaną versionwłaściwość:

@Entity
public class MyEntity implements Serializable {    

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @Version
    private Long version;

    //...
}

Po aktualizacji pole z adnotacją @Versionzostanie zwiększone i dodane do WHEREklauzuli, coś takiego:

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

Jeśli WHEREklauzula nie pasuje do rekordu (ponieważ ta sama jednostka została już zaktualizowana przez inny wątek), dostawca trwałości wyrzuci plik OptimisticLockException.

Czy to oznacza, że ​​powinniśmy zadeklarować nasze pole wersji jako ostateczne

Nie, ale możesz rozważyć zabezpieczenie rozgrywającego, ponieważ nie powinieneś tego nazywać.

Chociaż odpowiedź @Pascal jest całkowicie poprawna, z mojego doświadczenia uważam, że poniższy kod jest pomocny w optymistycznym blokowaniu:

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

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

    // ...
}

Czemu? Ponieważ:

1. Optymistyczne blokowanie nie zadziała, jeśli pole z adnotacją @Versionjest przypadkowo ustawione na null.
2. Ponieważ to specjalne pole niekoniecznie jest wersją biznesową obiektu, aby uniknąć wprowadzenia w błąd, wolę nazwać takie pole optlockraczej niż version.

Pierwszy punkt nie ma znaczenia, jeśli aplikacja używa tylko JPA do wstawiania danych do bazy danych, ponieważ dostawca JPA będzie wymuszał 0dla @versionpola w czasie tworzenia. Ale prawie zawsze używane są również proste instrukcje SQL (przynajmniej podczas testów jednostkowych i integracyjnych).

Za każdym razem, gdy jednostka jest aktualizowana w bazie danych, pole wersji zostanie zwiększone o jeden. Każda operacja aktualizująca jednostkę w bazie danych zostanie dołączona WHERE version = VERSION_THAT_WAS_LOADED_FROM_DATABASEdo jej zapytania.

Sprawdzając wiersze operacji, których dotyczy problem, struktura jpa może upewnić się, że nie nastąpiła równoczesna modyfikacja między ładowaniem a utrwalaniem jednostki, ponieważ zapytanie nie znajdzie jednostki w bazie danych, gdy jej numer wersji został zwiększony między ładowaniem a utrwalaniem.

Wersja używana w celu zapewnienia, że ​​tylko jedna aktualizacja na raz. Dostawca JPA sprawdzi wersję, jeśli oczekiwana wersja już się zwiększy, to ktoś inny już zaktualizuje jednostkę, więc zostanie wyrzucony wyjątek.

Tak więc aktualizacja wartości jednostki byłaby bezpieczniejsza i bardziej optymistyczna.

Jeśli wartość zmienia się często, możesz rozważyć nieużywanie pola wersji. Na przykład „jednostka, która ma pole licznika, które będzie się zwiększać za każdym razem, gdy otwierana jest strona internetowa”

Dodam trochę więcej informacji.

JPA zarządza wersją pod maską za Ciebie, jednak nie robi tego, gdy aktualizujesz rekord za pośrednictwem JPAUpdateClause, w takich przypadkach musisz ręcznie dodać przyrost wersji do zapytania.

To samo można powiedzieć o aktualizacji przez JPQL, tj. Nie jest to prosta zmiana encji, ale polecenie aktualizacji do bazy danych, nawet jeśli odbywa się to przez hibernację

Pedro