Нет, Hibernate ничего сам не разрулит.
При этом Hibernate это только инструмент, и прежде чем вы его начнете применять, хорошо бы понимать как он работает.
Поэтому для начала нужно понять две вещи
1) Теория заключается в том что надо выбрать между
- Пессимистической блокировкой, которая на уровне БД выглядит как SELECT FOR UPDATE. (Блокировка простая и надежная, но она выстраивает запросы в очередь и под высокой нагрузкой и при большой конкуренции начинаются сложности.) ... и оптимистичной блокировкой, которая достаточно просто реализована в хибере в виде @Version поля. Обе транзакции вычитывают свободные помидоры, обе пытаются их отнять от общего количества, но если это происходит одновременно, то одна из транзакций выхватывает исключения оптимистической блокировки. И уже вам как кодеру нужно решить что вы делаете с этим исключением.
Это решение хорошее, но нужно правильно продумывать обработку исключения.

2) Практика же иногда предлагает на много более простые решения, как например, SQL запрос выборки с одновременной валидацией значения.

lor2я нашел вот это:
setProperty("hibernate.connection.isolation", "2");

Это вам не надо.

lor2где уровень указвается. и да, что то читал насчет версионинга но в инете инфы как то маловато. значит люди с этим не сталкиваются.
Все сталкиваются. Вы, возможно, не так искали.


lor2в практике же "посчитать количество помидор и отнять помидоры" это слишком коротакая транзакция и может действительно с этим по этой причине и не сталкиваются.
Кстати, это хорошее дополнение к моему комментарию выше. Для короткой транзакции пессимистичная блокировка позволительна.
Для длинной же "вычитать кол-во доступных помидоров, затем через N минут закомитить измененний" пессимистичная блокировка не подходит вообще.

lor2скулем пользвоаться бы не хотелось по возможности.

Почему?

lor2касательно аннотации @Version тоже не совсем ясно для меня как оно работает. я что ставлю эту аннотацию и проблема решена чтоль?
Нет. У тебя есть запись Помидоры, 20, v1. Её вычитывают 2 клиента. Затем оба пытаются обновить её:
-15 (Помидоры, 5, v2)
-10 (Помидоры, 10, v2)
Первый успевает, второй получает исключение, потому что в базе v2 и у него v2.
v2 это поле помеченое @Version.


lor2чуть ранее я задавал тут похожий вопрос - мне сказали - когда засовываешь всё в одну транзакцию то типа "так не будет" :)
Сложно дать точный ответ на помидорах. Нужно точное описание процесса и транзакции.

забыл ник


Можно даже что-то типа
UPDATE pomidors SET count = count - order.count WHERE count >= order.count.
И потом смотреть количество измененных записей.

lor2теперь вопрос - как устанавливать тип блокировки в хибере на отдельные транзакции? :)
Не понял вопроса. Добавляешь поле и @Version на него и получаешь результат. Какие ещё "отдельные транзакции"?

забыл никВ вашем случае хибер сам не разрулит, даже с аннотацией Version.
Почему нет?

забыл никПотому что было 30 помидоров, один заказ на 10 и второй на 10, оба вычитали что каунт = 30, первый успешно закомиттил и коунт стал 20, второй пробует сделать update count where count =30, получает отлуп, и тут уже надо разбираться? Нет ну можно замутить какой-то retry, но это усложнение с неочевидным профитом. Те варианты проще
Ну, да. Всё зависит от системы и требований.
Имеет ли смысл показать сообщение пользователю "ой а помидоров уже 20, а не 30", если он хотел резервировать всего 10? Где-то имеет, а где-то нет. Зависит от требований.

lor2может быть, но блин. неужель без скуля никак не получится обойтись? :) я ведь даже выборки по критериям стараюсь делать. чтоб скуэля по минимуму.
На HQL/JPQL можно запрос написать. Стремиться к критериям ради критериев? Зачем? HQL проще читается.

lor2но я же могу повторно просто чек сделать и всё. если снова вылетает я снова чек делаю и до тех пор пока либо оно не отнимет и не закоммитит резервацию либо пока меньше нуля не станет и оно не вернется сообщением юзеру.
не знаю правда, как этот подход с точки зрения красоты.
Нормальный подход, если есть гарантия выхода из цикла.

забыл никНесомненно можно, выглядеть будет некрасиво и не совсем очевидно, это я сразу скажу. Но опять же все зависит от вас и от вашей системы. Лично я бы добавил просто констрейнт в базу. В крупном проекте предпочтителен вариант Leonida. Как видите проблему можно решить многими путями
На самом деле это вполне себе красиво. Во-первых калькуляции могут быть сложнее чем обычное вычитание. И тут у нас вычисления все на Java, а не скомбинированы с QL. Это и есть цель ORM - держать логику на Java.
Во-вторых повтор транзакции после OptimisticLockException это стандартная практика. Вопрос только в том до какого уровня транзакцию откатить.
Констрейнта в базе это никак не отменяет, конечно. Но он нужен только для целостности данных, а не для валидации.

забыл никПри большой нагрузке и короткой транзакции лучше использовать пессимистическую блокировку
С этим я в корне не согласен. Большая нагрузка требует отказаться от каких либо "блокировок" вообще. Optimistic Lock ничего не блокирует. А Pessimistic Lock выстраивает транзакции в очередь и становится, если не источником проблем, то как минимум узким местом.

lor2а пессимистическую блокировку в хибере можно делать только так?

авторSELECT count FROM inventory_total WHERE item_id = :id FOR UPDATE -- Поставили блокировку
-- Какая-то логика
UPDATE SET count=new_count inventory_total WHERE item_id = :ID
COMMIT

т.е. я в любом случае должен буду через скуль помечать строку в таблице фор апдейт, перед тем как сравнить значения, а после того как апдейт произошел (или не произошел) я снимаю?
Нет. Вы же привели код выше. Посмотрите в мануале, там должно быть с примерами. Раздел такой точно есть.

забыл никСоглашусь, тогда когда бы вы рекомендовали использовать пессимистик?
Когда этого явно требует бизнес-логика приложения.

lor2а такой вопрос. ексепшн при оптимистической блокировке через вершн будет выкидываться из транзакции или из метода, который применяет изменения внутри транзакции? я к чему спрашиваю - где его ловить и как обрабатывать )
В идеале у вас есть 2 класса
1) Класс Domain Model отвечающий за бизнес-логику. Возможно Service. Так, вот валидация количества, перехват OptimisticLockException и его обработка это бизнес-логика.
2) Класс Repository (иногда DAO) отвечающий за доступ к ORM. Это тот самый класс, который делает UPDATE сущности и выкидывает OptimisticLockException.

В идеале, конечно, надо смотреть где коммит в базу происходит. Либо на session.flush(), либо на session.commit(), либо на выходе из @Transactional метода.

Leonid Kudryavtsevто оптимистическая будет неудачными ретраями забивать и апп.сервер и базу.
Неудачные ретраи на много проще убрать.

Leonid KudryavtsevАдмин базы или надзирающая софтина пессимистическую блокировку и/или деадлок увидит
Сначала его увидят юзеры, когда блокировочная RDBMS вдруг решить что больно много у нас тут блокировок, а ну всем транзакциям стой раз-два.

Leonid KudryavtsevБлокировка - нормальная, штатная функция БД. Никаким источником проблем (при отсутвие кривых рук программистов) не становится.
Никто не спорит. Но чем меньше у нас блокировок тем больше у нас шансов выдержать увеличение нагрузки на систему.
А чем больше у нас блокировок, тем больше у нас шансов что система встанет в самый непредвиденный момент

Leonid KudryavtsevИ незачем подменять штатные функции БД изобретенным велосипедом в виде "ретраев" IMHO

Это не велосипед. И как я уже указал выше, если решил повторить транзакцию, то будь уверен, что система не решит повторять её вновь и вновь. Риск от кривой реализации есть в обоих сценариях.

Leonid KudryavtsevAFAIK Оптимистическая блокировка больше придумана для GUI. Когда оператор открыл запись на редактирование и полчаса ее держит. Тогда да, оптимистическая блокировка имеет право на жизнь.

Об этом всём я уже написал выше в теме.

Leonid KudryavtsevАрхитектуру БД нужно нормальную делать. Что бы взаимных блокировок при вычислениях было меньше и деадлоки в БД на каждом шагу не возникали.
Ну, вот если на каждый пук мы будем делать SELECT FOR UPDATE, то никуда от дедлоков потом не спрячешься. А если так уж так повелось что сервер какой-нибудь MySQL, то всё ещё хуже.

lor2сейчас у меня в приложении три слоя - дао, сервис, контроллеры. @Transactional естественно на уровне сервиса. я не понимаю ОЛЕ выкинет меня сразу же из метода с меткой @Transactional или... где??
Можно явно вызвать коммит у сессии и там ловить исключение.