Мне показали билет, где @Lock(LockModeType.PESSIMISTIC_WRITE) использует кэшированное значение
Пример:
Есть модель авторизации:
public class Authorization {
...
@ManyToOne
@JoinColumn(name = "wallet_id", nullable = false)
private Wallet wallet;
...
}
Запрос сделан
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select a from Authorization a " +
"where ((a.id in ?1)")
List<Authorization> findAllAuthorize(Set<UUID> authorizeList);
Здесь генерируется несколько запросов, когда авторизация извлекается для обновления, но создается отдельный запрос для извлечения кошелька, и этот запрос извлекается не для обновления (так как мы не используем что-то вроде join fetch a.wallet w ").
После некоторых действий создается новый запрос, например
@Lock(LockModeType.PESSIMISTIC_WRITE)
List<Wallet> findByOwnerIdIn(Set<String> ownerIds);
Но здесь по какой-то причине кошельки из первого запроса кэшируются и используются вместо выбора для обновления, поэтому кошельки фактически не заблокированы.что приводит к проблеме параллелизма.
Так что мой вопрос - это ожидаемое поведение. Можно ли каким-то образом убедиться, что второй запрос не будет использовать результаты первого запроса, но сделает запрос к базе данных с использованием весенних аннотаций данных?