Голосование

На какой стороне должно быть управление транзакциями?

Только зарегистрированные пользователи могут принимать участие в этом опросе.
8 участников проголосовало.

На стороне БД	4		50%
На стороне клиента	1		13%
На светлой стороне	0		0%
Мне пофиг, лишь бы человек был хороший	3		37%

---

Всем привет. А давайте поболтаем на тему транзакций?

Так исторически сложилось, что все мои сопровождаемые проекты за последние N-лет построены приблизительно по одному и тому же принципу - трехзвенка, БД на Оракле, сервер приложений, клиент на джаве. При этом управление транзакциями всегда на клиенте, что вызывает ряд проблем. Как обычно, ит-компании пытаются экономить на жабистах в результате чего понабирали хренпоймикого с улицы их квалификация зачастую вызывает сомнения. Например, на кнопку сохранения обычно навешивается целый "паровоз" процедур и функций, после вызова каждой из которых нужно проанализировать возвращаемый ответ, принять решение о целесообразности выполнения невыполненных, фиксации или откате изменений. На практике же зачастую жабисты косячат - шлют в параметры полную хрень, продолжают выполнение после возврата ошибки, фиксируют часть изменений и т.д. Для разработчиков БД это является источником неиссякаемого гемора.

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

Собственно вопрос: всегда ли управление транзакциями должно быть на стороне клиента? На какой стороне, по вашему мнению, оно должно быть? Что мешает фиксировать/откатывать изменения на стороне бд, возвращая клиенту лишь код успеха/ошибки?

Pekpytep

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

Собственно вопрос: всегда ли управление транзакциями должно быть на стороне клиента? На какой стороне, по вашему мнению, оно должно быть? Что мешает фиксировать/откатывать изменения на стороне бд, возвращая клиенту лишь код успеха/ошибки?

1. Теоретически, предложение вызывать "мастер" ХП из которой вызывается паровоз бизнес логики - правильный!! (я сам стараюсь так делать)

2. Практически, проще разделить сохранение мастер-детали на две ХП, что большинство делает (кол-во ХП/ф-ий на порядок, а то и два уменьшается), НО в этом случае необходима клиентская транзакция, что бы вызывать несколько ХП, что собственно front-end и делает.

3. Сильно упрощает (иногда усложняет) жизнь перенос бизнес-логики в триггеры/ограничения, те массу работы по проверке данных находится в тех же самых серверных объектах, использование такого механизма уменьшает кол-во проверочных ХП/ф-ий.

Вывод:
а) переносим бизнес логику на уровень БД.
б) из клиента вызываем только ОДНУ (мастер) ХП.
в) используем клиентскую транзакцию только для заполнения промежуточных сущьностей необходимых для работы мастер ХП.





Исправлено 1 раз(а). Последнее : PaulWist, 26.05.20 11:22

В 3-х звенке транзакциями управляет средний слой.

В БД транзакции конечно же могут быть, но как правило это какие-то автоматически выполняемые процессы, а не ХП вызываемая прикладным кодом.

Очевидный минус управления транзакциями из ХП состоит в том, что тогда ХП становится не тем чем она должна быть, а частью бизнес-логики приложения (а такая логика сложна и разнообразна). А значит для работы с одними и теми-же таблицами будет необходимо не 1 хп, а 100500 делать - на каждый возможный вариант использования.

Ну и естественно, это никак не помешает криво написанному бэк/фронт коду засылать в БД логически некорректные данные, которые БД не может да и не должна валидировать.

Не стоит перегружать БД логикой - особенно постоянно меняющейся и очень гибкой "бизнес-логикой". БД (включая код ХП!) должна быть максимально стабильной, все постоянные изменения и весь бедлам как раз и именуемый "бизнес-логикой" стоит убрать из БД.

Все эти рассуждения хороши в теоретическом плане, но на практике это почти никогда так не работает. Да, когда я самостоятельно работаю над проектом с нуля, стараюсь дробить функции на атомарные операции с целью максимально эффективного повторного использования. Да, бизнес-логика максимально на клиенте (я о VFP в качестве клиентской части, если что). На практике в поддержке существующих проектов никогда в чистом виде такого не встречал - бизнес-логика неизбежно в той или иной степени присутствует в хп, зачастую с укрупнением блоков, сложными ветвлениями и десятками операций исключающими повторное использование.
Да, в теории разделение выглядит красиво, в реальности же недостатков тоже более чем достаточно. Для базы клиент и сервер приложений - "черные ящики". Когда что-то не работает у нас жабист обычно заявляет, что у него все хорошо и ты начинаешь искать проблемы, которых нет на стороне бд. Дебажишь, делаешь тестовые кейсы, гоняешь так, сяк, вдоль и поперек только чтобы продемонстрировать жабисту что на стороне бд все работает как задумывалось. И спустя 2-4 часа тупой бессмысленной работы он таки признает что косяк на стороне клиента. ЪУЪ, бесит.
Кстати, а что на счет надежности? В трехзвенке это три разных хоста, находящиеся в разных подсетях. Что если посреди "паровоза" функций отвалится по сети бд? Должен произойти откат или фиксация? Тут вообще-то еще надо поразмыслить, какой из этих вариантов хуже. При управлении транзакциями на стороне бд вероятность нарушения целостности данных сильно меньше.

А совет представителя Майкрософт Цингауза на этом форуме не применять клиентские транзакции опять все забыли?

WbrErr
А совет представителя Майкрософт Цингауза на этом форуме не применять клиентские транзакции опять все забыли?

Что-то я такого не помню, скорее всего рассматривалась какая-то специфическая ситуация.

Клиентские транзакции нужны, а для каких целей их использовать - это отдельная тема.

Что-то как-то опять все в кучу свалили и каждый думает о чем-то своем. Сугубо личном О чем, собственно, речь-то?

Физически, сама по себе транзакция - это свойство базы данных и никак иначе. А где Вы транзакцию-то делаете?

Я так понимаю, вопрос заключается в том, кто должен давать команды на начало и окончание транзакции, следить за уровнем вложенности транзакций, поведением при возникновении исключения внутри транзакции и т.д. и т.п. По логике вещей, этим должен заниматься тот, кто формирует и запускает на выполнение команды на модификацию данных. Если модификация на клиенте, значит - клиент. На среднем слое - средний слой.

Понятно, что если код модификации "размазан" по всем слоям многозвенной архитектуры, то это все превращается в нечто слабо-управляемое. Значит, необходимо вводить какие-то правила написания кода. Эти "правила" могут быть как запрограммированы через некий FrameWork, так и просто быть неким "сводом правил" (Best Practices) в рамках проекта ("у нас так принято").

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


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


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

PaulWist

WbrErr
А совет представителя Майкрософт Цингауза на этом форуме не применять клиентские транзакции опять все забыли?

Что-то я такого не помню, скорее всего рассматривалась какая-то специфическая ситуация.

Клиентские транзакции нужны, а для каких целей их использовать - это отдельная тема.

Специфическая, но рассматривается.
forum.foxclub.ru



Исправлено 1 раз(а). Последнее : WbrErr, 27.05.20 22:09

Было дело, давноооо

Владимир Максимов
О чем, собственно, речь-то?

Да, проблема носит организационный характер. Вопрос в том, возможно ли решить часть организационных проблем за счет частичного изменения архитектуры.
Собственно, хотелось бы услышать всего пару вещей.
Во-первых, что управление транзакциями на стороне БД не является крамолой или преступлением как пытаются мне "доказать" некоторые мои коллеги. И речь не только о каких-то процессах или системах без UI типа ETL, DWH и т.д.
Во-вторых, услышать конкретные аргументы за и против. Потому как обычно когда я затрагиваю эту тему, слышу в качестве аргументации "не надо", "не стоит", "так нельзя", "это плохо" и т.д. Не доводы о том что это противоречит какой-то там абстрактной теории, а приземленные практические аргументы.
Вот смотрите, является ли перепланировка квартиры вмешательством в архитектурный проект? Да. Чем это плохо? Тем, что изменяется прочность здания, оно может разрушиться. Является ли вмешательством в конструкцию пристройка к историческому зданию снаружи шахты лифта с пробиванием к нему дверных проемов от лестничного пролета, как это зачастую принято в СПб? Да. Плохо ли это? Изменяется внешний вид, прочность изменяется незначительно, удобство пользования возрастает на порядок. Понимаете о чем я?
Давайте на минуту представим что я только что с пальмы слез или рептилоид с Нибиру. Я ничего не знаю о теории бд, нормальных формах, трехзвенной архитектуре и мне на нее глубоко наплевать. Перестанет ли приложение работать после переноса контроля транзакций на сторону БД? Нет. Станет ли оно работать менее стабильно? Нет. Увеличится ли вероятность нарушения целостности данных? Нет. В общем-то для конечного пользователя не изменится ровным счетом ничего, он даже не заметит каких-либо изменений. Предполагает ли перенос TCL на БД изменение инфраструктуры? Нет. Изменятся ли организационные процессы в разработке, перераспределится ли нагрузка между разработчиками? Да. Вот что примерно я хотел бы услышать.

Igor Korolyov
для работы с одними и теми-же таблицами будет необходимо не 1 хп, а 100500 делать - на каждый возможный вариант использования

Не очень понял мысль. Есть кнопка сохранения, которая, предположим, вызывает последовательно 3 процедуры, смотрит код ошибки и фиксирует/откатывает изменения. Первая из них p_add, в которой проверяются входные параметры и тупо insert into table. Если я оберну эти 3 процедуры процедурой p_save_button в которой будет контроль исключений и TCL, то просто добавится процедура на 30 строк, в остальном ничего не изменится, нет никаких 100500 процедур на все случаи жизни.

Что вкладывается в понятие "контроль транзакции"?

1. Если было начало транзакции, то обязательно должно быть завершение транзакции
2. Если было прерывание транзакции из-за исключительной ситуации, то
2.1. Выполняется откат транзакции (до какого уровня?)
2.2. Выполняется переход в программном коде (куда?)

Предположим, мы переносим управление транзакции на уровень базы данных. Т.е. мы должны каким-то образом решить все эти поставленные вопросы

Ну, инструменты для отслеживания уровня вложенности транзакции в базе данных должны быть. Т.е. п.1 решить можно.

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

А вот с тем, как должно прореагировать само приложение на этот откат - проблема. База данных ведь ничего не знает о самом приложении. Она с данными работает. Более того, здесь должна база данных неким образом начать "рулить" приложением. Напрямую дать команду приложению перейти на выполнение определенных строк кода. Я как-то смутно себе представляю как это можно сделать...


В самом приложении логика понятная

try (...)
catch (...)

Внутри try и catch может быть обращение к базе данных. Обратились к базе данных, получили ответ и по этому ответу дальше работаем

Но если мы "смотрим" со стороны базы данных, то как? Как заставить приложение что-то там начать выполнять в случае ошибки в базе данных?

Лично я вижу только дублирование управления. Все тот же try..catch со стороны приложения. Но если часть контроля невозможно убрать из приложения, то зачем усложнять систему делая, по сути, распределенный контроль (часть в приложении, часть в базе данных)?

Владимир Максимов
1. Если было начало транзакции, то обязательно должно быть завершение транзакции
2. Если было прерывание транзакции из-за исключительной ситуации, то
2.1. Выполняется откат транзакции (до какого уровня?)
2.2. Выполняется переход в программном коде (куда?)

Что-то п.2.2 я не понял, какой переход в программном коде?Этот переход на клиенте или в БД?

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

Владимир Максимов

А вот с тем, как должно прореагировать само приложение на этот откат - проблема. База данных ведь ничего не знает о самом приложении. Она с данными работает. Более того, здесь должна база данных неким образом начать "рулить" приложением. Напрямую дать команду приложению перейти на выполнение определенных строк кода. Я как-то смутно себе представляю как это можно сделать...

Хммм, странный вопрос... проанализировать код возврата ХП, а дальше приложение решает само в какой программный модуль идти.

Кстати, об этом Pekpytep пишет, что front-end открывает клиентскую транзакцию или даже не делает этого, а в режиме автокоммита просто "дергает" несколько ХП/ф-ий/команд подряд и не смотрит на код ошибки считая, что батч выполнился успешно.
Если по дороге что-то сработало с ошибкой, то front-end не обращает внимание и коммитит транзакцию, получая не консистентные данные в бизнес логике.

Поэтому, ТС хочет перенести код сохранения в ХП реализующую логику происходящую на клиенте, что бы избежать таких косяков.

Владимир Максимов

В самом приложении логика понятная

try (...)
catch (...)

Внутри try и catch может быть обращение к базе данных. Обратились к базе данных, получили ответ и по этому ответу дальше работаем

Но если мы "смотрим" со стороны базы данных, то как? Как заставить приложение что-то там начать выполнять в случае ошибки в базе данных?

Хммм, вот же слова дающие ответ:

Владимир Максимов
Обратились к базе данных, получили ответ и по этому ответу дальше работаем

Владимир Максимов
Лично я вижу только дублирование управления. Все тот же try..catch со стороны приложения. Но если часть контроля невозможно убрать из приложения, то зачем усложнять систему делая, по сути, распределенный контроль (часть в приложении, часть в базе данных)?

Какой распределенный контороль? В ХП try (...) catch (...), те СУБД обрабатывает СВОИ ОШИБКИ, клиент обрабатывает свои ошибки, от БД клиент обрабатывает коды/сообщения возврата.





Исправлено 1 раз(а). Последнее : PaulWist, 28.05.20 18:17

Igor Korolyov
В 3-х звенке транзакциями управляет средний слой.
В БД транзакции конечно же могут быть, но как правило это какие-то автоматически выполняемые процессы, а не ХП вызываемая прикладным кодом.

Очевидный минус управления транзакциями из ХП состоит в том, что тогда ХП становится не тем чем она должна быть, а частью бизнес-логики приложения (а такая логика сложна и разнообразна). А значит для работы с одними и теми-же таблицами будет необходимо не 1 хп, а 100500 делать - на каждый возможный вариант использования.

Ну и естественно, это никак не помешает криво написанному бэк/фронт коду засылать в БД логически некорректные данные, которые БД не может да и не должна валидировать.

Не стоит перегружать БД логикой - особенно постоянно меняющейся и очень гибкой "бизнес-логикой". БД (включая код ХП!) должна быть максимально стабильной, все постоянные изменения и весь бедлам как раз и именуемый "бизнес-логикой" стоит убрать из БД.

@Игорь плз обоснуй выделенное на практических твоих примерах

на прошлой работе 2 звенка
апликухи из дельфи дергали T-sql SP на БД
( по факту там получался микс - ибо в SP часто передавали )
но логика вся (95%)сидела именно в SP

ЗЫ вопрос коненчо интресный
т.е когда я писал на фоксе к-й хорошо знал мен было удобней логику на клиенте
когда я выучил t-sql - теперь мне удобней там (хотя язык конечно ограниченный и сильно)

опять же - одно дело когда идут прямые запросы в БД а ля sql exec
другое дело - их генерит какой-то фреймворк - о тут ПЕСНЯ может быть сразу
вместо одного запроса на 1000 записей - он грубо говоря сгенерит 1000

PS
@Рекрутер - МОЛОДЦА - давно не было на проф. тему обсуждений
как-то выродился форум аж обидно - а так смотришь еще все таки можно обсудить чего-то по профессии
не только треп.



Исправлено 2 раз(а). Последнее : Гулин Федор, 28.05.20 18:29

PaulWist
1. Теоретически, предложение вызывать "мастер" ХП из которой вызывается паровоз бизнес логики - правильный!! (я сам стараюсь так делать)
2. Практически, проще разделить сохранение мастер-детали на две ХП, что большинство делает (кол-во ХП/ф-ий на порядок, а то и два уменьшается), НО в этом случае необходима клиентская транзакция, что бы вызывать несколько ХП, что собственно front-end и делает.
3. Сильно упрощает (иногда усложняет) жизнь перенос бизнес-логики в триггеры/ограничения, те массу работы по проверке данных находится в тех же самых серверных объектах, использование такого механизма уменьшает кол-во проверочных ХП/ф-ий.

Вывод:
а) переносим бизнес логику на уровень БД.
б) из клиента вызываем только ОДНУ (мастер) ХП.
в) используем клиентскую транзакцию только для заполнения промежуточных сущьностей необходимых для работы мастер ХП.

это как бы оффтоп - но мне интересно - думаю может еще кому
с а) ок - допустим решили и делаем так.
б) - имеется ввиду ОДНА мастер SP для сохранения данных
- одна в принципе вообще ??
и пример (я надеюсь в T-sql) наименования , Параметров , и пример вызова
мне не очень понятна универсальность и как это реально может работать

про в) я честно тоже не понял - можно сюда же всунуть в ответ пример чего и как.



Исправлено 1 раз(а). Последнее : Гулин Федор, 28.05.20 18:36

PaulWist
б) из клиента вызываем только ОДНУ (мастер) ХП.

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





Исправлено 3 раз(а). Последнее : Божья_коровка, 28.05.20 18:56

Гулин Федор
а так смотришь еще все таки можно обсудить чего-то по профессии
не только треп.

Особенно полезно почитать, чего пишут умные люди





Исправлено 1 раз(а). Последнее : Божья_коровка, 28.05.20 18:59

Я вообще не понимаю, почему эта тема в курилке.

WbrErr
Я вообще не понимаю, почему эта тема в курилке.

Скорее всего потому что автор не работает с фоксом уже давно. Pekpytep ораклист, плюс он дал такое "философское" наименование темы, что оно не подходит для проф.топика. Можно было тему закинуть в топик - Не фоксом единым, но там проходимость низкая. В Курилке больше людей слоняются без дела чтобы поболтать. Видимо из этих соображений автор и поместил сюда тему.





Исправлено 3 раз(а). Последнее : Божья_коровка, 28.05.20 19:06

Владимир Максимов
Что вкладывается в понятие "контроль транзакции"?

Под контролем транзакции я вкладывал исключительно смысл TCL - savepoint to/commit/rollback включая неявные транзакции.

PaulWist
Кстати, об этом Pekpytep пишет, что front-end открывает клиентскую транзакцию

Да, Паша правильно уловил суть, но похоже не все поняли о чем речь. Давайте еще раз подробнее объясню.
Мое знание джавы недостаточно чтобы однозначно сказать как и что оно у них там происходит, но должно происходить примерно следующее:
1. открывается явная/неявная транзакция (но это не точно)
2. вызывается процедура1 на стороне бд (в которой весь DML, перехватываются и обрабатываются оракловские исключения и в out-параметр возвращается код и текст ошибки/успеха на человеческом языке)
3. клиент смотрит код ошибки, если ок, то продолжаем, иначе - откат изменений, прерывание выполнение, выброс в интерфейс окна с ошибкой
4. запуск процедуры2
5. см.п.3
6. процедура 3
7. см.п.3
8. если все 3 ок, то фиксируем изменения

На практике же бывает косячат и все это дело приобретает вид:
1. процедура1
2. процедура2
3. процедура3
4. commit
т.е. клиент либо не анализирует код ответа от процедур, либо некорректно его обрабатывает, при этом крайне сложно найти и ликвидировать причину когда джава-разработчики включают дурака и уходят в несознанку.

Собственно, все это безобразие можно модифицировать следующим образом:
Весь первый блок из 8 пунктов вкладываем внутрь процедуры p_save_button, которая на стороне бд будет рулить транзакциями, анализировать код ошибки и фиксировать/откатывать изменения. На стороне клиента это упрощается до вида:
1. вызвать p_save_button, передав туда параметрами нужные значения
2. показать окно с ошибкой или успехом
Да, и здесь можно передать чушь в параметры, но теперь возможностей накосячить меньше и на стороне бд больше возможностей быстро найти и ликвидировать ошибку. Да, это выходит за рамки классической теории трехзвенки, но тут "либо шашечки, либо ехать".

WbrErr
Я вообще не понимаю, почему эта тема в курилке.

Потому что я тут усиленно игнорирую теории, нарушаю парадигмы и несу ересь.
На серьезное обсуждение не тянет.

Гулин Федор
имеется ввиду ОДНА мастер SP для сохранения данных
- одна в принципе вообще ??

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