Нет, 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 проще читается.