ViPRosДмитрий МухProga,

я видео не смотрел и, соответсвенно, не в курсе как там конкретно выстроено управление транзакциями не на сервере БД

но лично для меня формулировка "это зло", потому что "базовики повесят", "взаимоблокировки разруливать будете", "500 пользаков ввели данные, жмут сохранить, а у них не сохранилось", выглядит, мягко говоря, не убедительно

последний раз сталкивался с блокировками из-за зависшей клиентской транзакции в 2004-м году, в большой монолитной ERP
если архитектура вашей системы застряла в том же времени, то проблемы скорее всго из-за неё, а не из-за транзакций не на сервере БД
У тебя просто нет общих данных
Сахават, ты как обычно зришь в корень.
У меня 40тыс. пользаков в корпоративной веб-системе, + 1200 бекэнд, в реал тайме порядка 15тыс. транзакций в секунду.
Ребята просто не сталкивались с оверхедами.

Всем добра.

skyANAViPRosпропущено...

У тебя просто нет общих данныхЧто ты подразумеваешь под общими данными?
можно я отвечу.
Работники работают на сменах.
Им проставляют всякие разные атрибуты к сменам, проставлятелей 100-120 человек + роботы.

Petro123ProgaУ меня 40тыс. пользаков в корпоративной веб-системе, + 1200 бекэнд, в реал тайме порядка 15тыс. транзакций в секунду.
можно иметь миллион транзакций, но они все не имеют отношения к взаимоблокировкам.
ProgaРебята просто не сталкивались с оверхедами.
Слово "оверхед" обозначает НЕНУЖНОЕ усложнение, решение или технология.
То есть у тебя оверхед?

ProgaРаботники работают на сменах.
Им проставляют всякие разные атрибуты к сменам, проставлятелей 100-120 человек + роботы.
Есть общие решения к вопросу параллельного доступа к общим ресурсам.
- короткие транзакции
- тип блокировки
- бд неблокировочник
и т.д.
Причём тут в теме про Core хранимки и транзакции в БД?
я прокомментировал видео с ютуба. И указал, что не очень согласен с подходами разработчика, который говорит о своём решении, как о готовой шаблонной конструкции при построении коммерческих приложений. Это моя личная точка зрения.
Оверхед для меня в данном случае, это не спланированая или неожидаемая нагрузка на систему, т.е. планировали при запуске количество транзакций в сек например 7-8 тыс, а заказчик решил подругому использовать - 12-15 тыс. Система в целом перестала справляться с такими нагрузками. Пришлось изменять архитектуру решения. Разруливать пришлось на уровне сервера БД.

skyANAProgaпропущено...

можно я отвечу.
Работники работают на сменах.
Им проставляют всякие разные атрибуты к сменам, проставлятелей 100-120 человек + роботы.
Ну и?

Блокировки в базе возникают на объектах этой самой базы.
В этом контексте, что подразумевается под общими данными? Что за СУБД? Какой уровень изоляции транзакций?
Про общие данные написал пример, не буду повторяться
СУБД -MS SQL Server 2016.
Блокировки изначально приняли те, что строит автоматический оптимизатор запросов. Однако после пришлось самим разруливать внутри хп.

Petro123Proga,
оказывается тема ушла в объяснения азов блокировок.
И, можешь обижаться, но ты сам эту тему не проработал.
Удачи!
не надо переходить на личности. компетентность мою и моих коллег не вам определять, вы не мой заказчик.

skyANAPetro123пропущено...

это я не понял.
Хинтами внутри хранимок видать стали разруливать.
да

skyANAProgaСистема в целом перестала справляться с такими нагрузками. Пришлось изменять архитектуру решения. Разруливать пришлось на уровне сервера БД.
А управление транзакциями не на сервере БД вообще было?
да, в первой версии так и сделали.
но получили фейл. может изначально с архитектурной точки зрения плохая проработка была с нашей стороны и понадеялись, что сможем разрулить на стороне сервера приложений, не смогли. Ушли в хранимки и финты ушами (хинты, optimistic lock и немного версионник)

Petro123Progaкомпетентность мою и моих коллег не вам определять, вы не мой заказчик.
Добро пожаловать в форум!
Тут судят исключительно по вашим текстам.
И то, только в профессиональном плане).
ок, без обид.