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, то всё ещё хуже.