Blazkowiczlor2при пессимистической блокировке если у меня запускается мешок транзакций, то несколько исполняются в очереди, а остальные сыпятся с ошибкой:
18835378
Я вам первым же сообщением написал что пессимистик не годится для высоких нагрузок. Сколько у тебя продавцов томатов что они усердно за них конкурируют? Если ты highload пишешь для высокой конкурентности, то тебе блокировки вообще не подходят ни в каком виде.
да это всё ясно конечно же. я о том, чтоб разобраться в нюансах работы. а вообще, у меня товарищ есть скулевец, он вообще лютый проповедник-пессимист. для него опт. принципиально не существует. ну видимо, мнений много разных.

в практике у меня продавцов томатов не так уж и много, но вероятность что забронят больше, чем есть на складе свободного (если не морочиться блокировками) есть. по факту я конечно же там сделал тупо версионность как страховку и всё.

Petro123,

ахахаха точно. оно и есть. значит они тоже мучаются с такими проблемами.

Петро, ты извини, я просто не умею думать скулем, я думаю хиберовскими шаблонами :) разумеется, если речь о транзакции то это в рамках хибера. скажу более речь (с моей стороны) идет в рамках методов, помеченных аннтотацией "транзакшионал". идею в общем то понял, просто для меня грань еще более размытой стала между лок на чтение и оптимистик. если я делаю лок на чтение то последующие транзакции типа "в очереди ждут" а потом отваливаются бросая ексепшн, если ждут "долго", в оптимистике у меня тупо сразу же если версия изменилась идет откат транзакции и так же вылетает ексепшн. в обоих случаях надо городить логику как себя вести при ексепшене. либо ждать либо юзера посылать подальше либо еще что-то.

Leonid Kudryavtsev,

я хз у меня есть валютная визакард, и действительно раз вышло что на алиюшке заказал два товара на сумму больше чем по карте и карта ушла в минус )) карта дебетовая. покупки делал подряд.

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

кстати, ткой вопрос в контексте спринга и его аопа.

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

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

Petro123lor2версионирование - без него по ходу никуда.
Ты не учился в ВУЗе? )))
Первое что делают - списывают и ищут "рыбу".
- найди аналог из сети твоего ВИ \ use case.
я учился в вузе 6 лет, но мое направление хоть и связано с техникой, но мало связано с программированием.


автор
По-умолчанию одна сессия на одну транзакцию. При остром желании это можно изменить, но нужно понимать что делаешь.


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

что лучше

BlazkowiczКороткие транзакции лучше, это в каждом букваре написано. Чем короче транзакции, тем меньше между ними соперничества, тем меньше системе нужно тратить ресурсов на разруливание конкуренции. А на тупых блокировочниках типа MySQL длинные транзакции это смерть системы под нагрузкой.
я по собеседованиям походил и такого наслушался, что уже сам себе не верю. да, я так же считаю как ты написал. вернее я так не считаю я так читал в куче источников.

Петро, так что там насчет помидоров то не так? процесс прост как дважды-два: есть помидоры - откусываем от доступных остатков - перекладываем в заброньканые остатки-коммитимся. нет помидоров - идем мимо.

по деньгам просто если параллельно вдруг так случится отработают две транзакции просто в худшем случае без всяких блокировок выйдет так что (кажется в 1с это регистр называется ) так вот регистр у клиента будет показывать на счету 100 рублей, а по факту (и по логу денежных транзакций) у него 150 рублей. это в самом худшем для него случае. надо просто пересчет делать.