всех с прошедшими праздниками, счастья здоровья и интересных проектов.

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

допустим такая ситуация, есть некая многопользовательская система, по отпуску товара, чтоб пример проще был. сидит десять операторов - бронируют отпускают и т.п. процесс бронирования заключается в проверке наличия на складе и блокирования части товара(блокирование бронирование - whatever) и вот такая ситуация:
оператор А) бронирует 10 пачек молока из 10-ти, система проверяет - да. есть такое количество.. но после брони останется ноль. следом в промежутке этого оператор б так же бронирует 10 пачек. функция проверки так же параллельно запускается и видит что на складе пока еще 10 пачек. и дает добро на запуск функции бронирования. следом нить оператора А бронирует и остаток доступный становится ноль. т.к. нить Б проверяла наличие и на тот момент оно было доступно она запустила функцию бронирования и так же бронирует 10 и опа на складе становится минус десять. собссно как этого избежать? вышло в данном случае так, что проверка нити Б началась на момент между проверкой и бронированием нити А.

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

вадя,

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

вот в чем казус.

далее, я так понимаю все транзакции выполняются ПОСЛЕДОВАТЕЛЬНО? в любом случае так да? т.е. не может быть такого что несколько транзакций идут параллельно? и они всё-равно выстраиваются в некую очередь?

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

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

Petro123,

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

вадя,

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

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

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

и, всё же, как выстраиваются транзакции в очередь в рамках связки спринг-хибер. если у меня есть один контроллер, внутри которого есть функции обернутые в транзакцию, скажем 2-3 штуки, контроллер вызывается десятком человек условно одновременно. как эти транзакции будут выстраиваться в очередь? "поконтроллерно"? или начнут фигачить одновременно - кто первый тот и папа?

нет не букал :) билеты на самолет покупал несколько раз :)

в общем,у меня есть слой дао, слой сервиса, слой бл. как у меня сейчас работает? с юзера приходит запрос забукать:
контроллер делает следующее: транзакция1(проверяем есть ли на складе?) если есть -- транзакция2(букаем). если нет - лови отлуп.
это делается в БЛ. насколько я понимаю, безопаснее было бы сдвинуть это всё в слой сервиса, который транзакции и создает. т.е. от юзверя приходит: хочу букнуть 100 штук товара. контроллер передает эти 100 штук в сервисный слой сразу, без валидации, сервисный слой создает одну транзакцию1(проверям достаточно ли - да хватает -- букаем -- отправляем саксесс, не хватает -- отправляем фейл).

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