SP
Я бы над методом, который запускается в транзакции Repeatable Read просто поставил бы Retryable вот и вся логика повтора. Нужно только правильно указать тип исключения.
Size: a a a
2021 January 26
AG
Да, такой вариант я тоже рассматривал, наверное, оптимальное решение
AG
Gerr Mes
Достаточно "хрупкий" код получается, кто то другой залезет и сломает - сделайте лучше на оптимистических блокировках - повторите проигравшую транзакцию ничего страшного
Согласен, можно и нарваться в будущем
AG
Моё долгосрочное решение - всё-таки будет убрать hibernate, уже столько с ним поел 😁
SP
Да, такой вариант я тоже рассматривал, наверное, оптимальное решение
Я так делал и оно отлично работает
SP
Моё долгосрочное решение - всё-таки будет убрать hibernate, уже столько с ним поел 😁
Это правильно. У хибера много неочевидного и неожиданного поведения. Поэтому, если хочется странного, то лучше без него. Можно использовать JdbcTemplate
GM
Моё долгосрочное решение - всё-таки будет убрать hibernate, уже столько с ним поел 😁
👍
AG
Сейчас посмотрел на код hibernate и похоже, что так и должно работать. Там у persistence context просто HashMap, в котором лежат все managed entity. Так что по-простому это не починить.
Всем спасибо, ушёл выбирать уже конкретное решение!
Всем спасибо, ушёл выбирать уже конкретное решение!
SP
дело еще и в том, что когда Вы вызываете метод save() то там под капотом JPA сначала пытается найти эту запись, чтобы понять, что делать INSERT или UPDATE, то есть запросов будет два, а не один.
AG
У меня save всегда вызывается на managed entity в данном случае, так что второго запроса не будет, насколько я понимаю
ЕФ
Нужно подсчитать нагрузку jvm. Имею ввиду потребляемую оперативную память а так же ресурсы процессора. В джаве есть что-то для этого?
Д
У меня save всегда вызывается на managed entity в данном случае, так что второго запроса не будет, насколько я понимаю
Можно сделать refresh и гибер возьмёт актуальное значение из базы
AE
Вот есть такой вопросик по hibernate + spring-data.
Я две одинаковые транзакции в разных потоках и в них делаю findById.
Потом делаю тоже самое, но с
Далее в первой транзакции делаю update и commit транзакции.
Тут лок отпускается и во второй транзакции получаю объект, но со старым значением (до update), потому что entity уже есть в persistence context. Делаю update и теряю предыдущий update.
Это ожидаемое поведение? Можно ли как-то настроить hibernate, чтобы второй select for update обновлял мою entity?
Я две одинаковые транзакции в разных потоках и в них делаю findById.
Потом делаю тоже самое, но с
PESSIMISTIC_WRITE-локом (т.е. select for update). Одна транзакция выигрывает, вторая зависает на локе.Далее в первой транзакции делаю update и commit транзакции.
Тут лок отпускается и во второй транзакции получаю объект, но со старым значением (до update), потому что entity уже есть в persistence context. Делаю update и теряю предыдущий update.
Это ожидаемое поведение? Можно ли как-то настроить hibernate, чтобы второй select for update обновлял мою entity?
Не ожидаемое. Должно во втором потоке обновлённое быть
AK
дело еще и в том, что когда Вы вызываете метод save() то там под капотом JPA сначала пытается найти эту запись, чтобы понять, что делать INSERT или UPDATE, то есть запросов будет два, а не один.
А как обстоят дела с merge под капотом JPA есть?
E
Нужно подсчитать нагрузку jvm. Имею ввиду потребляемую оперативную память а так же ресурсы процессора. В джаве есть что-то для этого?
Я думаю это надо прям в системе смотреть
htop и все такое
htop и все такое
AE
Нужно подсчитать нагрузку jvm. Имею ввиду потребляемую оперативную память а так же ресурсы процессора. В джаве есть что-то для этого?
Spring boot? Если да, то включаем актуатор Прометея. Если нет, то есть jmx exporter
A
Нужно подсчитать нагрузку jvm. Имею ввиду потребляемую оперативную память а так же ресурсы процессора. В джаве есть что-то для этого?
Ещё как вариант, профилировщики вам помогут
AG
Не ожидаемое. Должно во втором потоке обновлённое быть
Странно. Я посмотрел код. Я попадаю вот сюда https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/loader/Loader.java#L1609
потом вот сюда https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/internal/StatefulPersistenceContext.java#L406
А здесь уже просто HashMap, в которой лежит старый Entity.
потом вот сюда https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/internal/StatefulPersistenceContext.java#L406
А здесь уже просто HashMap, в которой лежит старый Entity.
AE
Странно. Я посмотрел код. Я попадаю вот сюда https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/loader/Loader.java#L1609
потом вот сюда https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/internal/StatefulPersistenceContext.java#L406
А здесь уже просто HashMap, в которой лежит старый Entity.
потом вот сюда https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/internal/StatefulPersistenceContext.java#L406
А здесь уже просто HashMap, в которой лежит старый Entity.
Хм. Значит я не прав. Надо будет посмотреть что там. По идее же транзакция == сессия, а между сессиями сущности не шарятся.
Если только не настроен L2 кэш, его нет?
Если только не настроен L2 кэш, его нет?
AG
Правильно, не шарятся. Но это воспроизводится как раз только для второго селекта внутри сессии. Первый у меня без for update, и если его выключить, то проблема пропадёт.
Кеш выключен, это точно
Кеш выключен, это точно