Светлая и темная сторона транзакций | |
---|---|
Pekpytep Автор Сообщений: 727 Откуда: Луганск Дата регистрации: 19.10.2010 |
Всем привет. А давайте поболтаем на тему транзакций? Так исторически сложилось, что все мои сопровождаемые проекты за последние N-лет построены приблизительно по одному и тому же принципу - трехзвенка, БД на Оракле, сервер приложений, клиент на джаве. При этом управление транзакциями всегда на клиенте, что вызывает ряд проблем. Как обычно, ит-компании пытаются экономить на жабистах в результате чего Предложил как-то раз коллегам-базистам (с оглядкой на существующие проблемы с профессиональностью наших коллег-джавистов) перенести управление транзакциями на сторону бд, т.е. обернуть "паровоз" функций мастер-функцией (типа p_save_button), из которой уже дергать все необходимые процедуры/функции, в т.ч. принимать решение о фиксации/откате изменений. На что всегда получаю минутный ступор и ответ а-ля "ну так низзя". Вменяемых аргументов от кого-бы то ни было так и не удалось добиться. Собственно вопрос: всегда ли управление транзакциями должно быть на стороне клиента? На какой стороне, по вашему мнению, оно должно быть? Что мешает фиксировать/откатывать изменения на стороне бд, возвращая клиенту лишь код успеха/ошибки? |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
1. Теоретически, предложение вызывать "мастер" ХП из которой вызывается паровоз бизнес логики - правильный!! (я сам стараюсь так делать) 2. Практически, проще разделить сохранение мастер-детали на две ХП, что большинство делает (кол-во ХП/ф-ий на порядок, а то и два уменьшается), НО в этом случае необходима клиентская транзакция, что бы вызывать несколько ХП, что собственно front-end и делает. 3. Сильно упрощает (иногда усложняет) жизнь перенос бизнес-логики в триггеры/ограничения, те массу работы по проверке данных находится в тех же самых серверных объектах, использование такого механизма уменьшает кол-во проверочных ХП/ф-ий. Вывод: а) переносим бизнес логику на уровень БД. б) из клиента вызываем только ОДНУ (мастер) ХП. в) используем клиентскую транзакцию только для заполнения промежуточных сущьностей необходимых для работы мастер ХП. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 26.05.20 11:22 |
Re: Светлая и темная сторона транзакций | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
В 3-х звенке транзакциями управляет средний слой.
В БД транзакции конечно же могут быть, но как правило это какие-то автоматически выполняемые процессы, а не ХП вызываемая прикладным кодом. Очевидный минус управления транзакциями из ХП состоит в том, что тогда ХП становится не тем чем она должна быть, а частью бизнес-логики приложения (а такая логика сложна и разнообразна). А значит для работы с одними и теми-же таблицами будет необходимо не 1 хп, а 100500 делать - на каждый возможный вариант использования. Ну и естественно, это никак не помешает криво написанному бэк/фронт коду засылать в БД логически некорректные данные, которые БД не может да и не должна валидировать. Не стоит перегружать БД логикой - особенно постоянно меняющейся и очень гибкой "бизнес-логикой". БД (включая код ХП!) должна быть максимально стабильной, все постоянные изменения и весь бедлам как раз и именуемый "бизнес-логикой" стоит убрать из БД. ------------------ WBR, Igor |
Re: Светлая и темная сторона транзакций | |
---|---|
Pekpytep Автор Сообщений: 727 Откуда: Луганск Дата регистрации: 19.10.2010 |
Все эти рассуждения хороши в теоретическом плане, но на практике это почти никогда так не работает. Да, когда я самостоятельно работаю над проектом с нуля, стараюсь дробить функции на атомарные операции с целью максимально эффективного повторного использования. Да, бизнес-логика максимально на клиенте (я о VFP в качестве клиентской части, если что). На практике в поддержке существующих проектов никогда в чистом виде такого не встречал - бизнес-логика неизбежно в той или иной степени присутствует в хп, зачастую с укрупнением блоков, сложными ветвлениями и десятками операций исключающими повторное использование.
Да, в теории разделение выглядит красиво, в реальности же недостатков тоже более чем достаточно. Для базы клиент и сервер приложений - "черные ящики". Когда что-то не работает у нас жабист обычно заявляет, что у него все хорошо и ты начинаешь искать проблемы, которых нет на стороне бд. Дебажишь, делаешь тестовые кейсы, гоняешь так, сяк, вдоль и поперек только чтобы продемонстрировать жабисту что на стороне бд все работает как задумывалось. И спустя 2-4 часа тупой бессмысленной работы он таки признает что косяк на стороне клиента. ЪУЪ, бесит. Кстати, а что на счет надежности? В трехзвенке это три разных хоста, находящиеся в разных подсетях. Что если посреди "паровоза" функций отвалится по сети бд? Должен произойти откат или фиксация? Тут вообще-то еще надо поразмыслить, какой из этих вариантов хуже. При управлении транзакциями на стороне бд вероятность нарушения целостности данных сильно меньше. |
Re: Светлая и темная сторона транзакций | |
---|---|
WbrErr Сообщений: 1960 Дата регистрации: 05.12.2006 |
А совет представителя Майкрософт Цингауза на этом форуме не применять клиентские транзакции опять все забыли?
|
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Что-то я такого не помню, скорее всего рассматривалась какая-то специфическая ситуация. Клиентские транзакции нужны, а для каких целей их использовать - это отдельная тема. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Светлая и темная сторона транзакций | |
---|---|
Владимир Максимов Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Что-то как-то опять все в кучу свалили и каждый думает о чем-то своем. Сугубо личном О чем, собственно, речь-то?
Физически, сама по себе транзакция - это свойство базы данных и никак иначе. А где Вы транзакцию-то делаете? Я так понимаю, вопрос заключается в том, кто должен давать команды на начало и окончание транзакции, следить за уровнем вложенности транзакций, поведением при возникновении исключения внутри транзакции и т.д. и т.п. По логике вещей, этим должен заниматься тот, кто формирует и запускает на выполнение команды на модификацию данных. Если модификация на клиенте, значит - клиент. На среднем слое - средний слой. Понятно, что если код модификации "размазан" по всем слоям многозвенной архитектуры, то это все превращается в нечто слабо-управляемое. Значит, необходимо вводить какие-то правила написания кода. Эти "правила" могут быть как запрограммированы через некий FrameWork, так и просто быть неким "сводом правил" (Best Practices) в рамках проекта ("у нас так принято"). Сложность здесь в том, что в этом случае требуется специально назначенный сотрудник, который будет следить за выполнением этих правил. Делать Code Review перед переносом модификаций на тест, не говоря уже о продуктиве. Специальный класс-обертка? Без ручного контроля, сам по себе, бесполезен. Я могу сразу сказать, что от разработчиков будет куча жалоб на то, что он не удобен, а вот здесь особый случай и надо бы что-то другое, да так вообще нельзя и т.п. Короче, по описанию, заявленная проблема носит организационный, а вовсе не программный характер. Поэтому решить эту проблему программными средствами невозможно. В данном случае, дополнительный класс-обертка только увеличит количество проблем, а не уменьшит их. |
Re: Светлая и темная сторона транзакций | |
---|---|
WbrErr Сообщений: 1960 Дата регистрации: 05.12.2006 |
Специфическая, но рассматривается. forum.foxclub.ru Исправлено 1 раз(а). Последнее : WbrErr, 27.05.20 22:09 |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Было дело, давноооо
------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) |
Re: Светлая и темная сторона транзакций | |
---|---|
Pekpytep Автор Сообщений: 727 Откуда: Луганск Дата регистрации: 19.10.2010 |
Да, проблема носит организационный характер. Вопрос в том, возможно ли решить часть организационных проблем за счет частичного изменения архитектуры. Собственно, хотелось бы услышать всего пару вещей. Во-первых, что управление транзакциями на стороне БД не является крамолой или преступлением как пытаются мне "доказать" некоторые мои коллеги. И речь не только о каких-то процессах или системах без UI типа ETL, DWH и т.д. Во-вторых, услышать конкретные аргументы за и против. Потому как обычно когда я затрагиваю эту тему, слышу в качестве аргументации "не надо", "не стоит", "так нельзя", "это плохо" и т.д. Не доводы о том что это противоречит какой-то там абстрактной теории, а приземленные практические аргументы. Вот смотрите, является ли перепланировка квартиры вмешательством в архитектурный проект? Да. Чем это плохо? Тем, что изменяется прочность здания, оно может разрушиться. Является ли вмешательством в конструкцию пристройка к историческому зданию снаружи шахты лифта с пробиванием к нему дверных проемов от лестничного пролета, как это зачастую принято в СПб? Да. Плохо ли это? Изменяется внешний вид, прочность изменяется незначительно, удобство пользования возрастает на порядок. Понимаете о чем я? Давайте на минуту представим что я только что с пальмы слез или рептилоид с Нибиру. Я ничего не знаю о теории бд, нормальных формах, трехзвенной архитектуре и мне на нее глубоко наплевать. Перестанет ли приложение работать после переноса контроля транзакций на сторону БД? Нет. Станет ли оно работать менее стабильно? Нет. Увеличится ли вероятность нарушения целостности данных? Нет. В общем-то для конечного пользователя не изменится ровным счетом ничего, он даже не заметит каких-либо изменений. Предполагает ли перенос TCL на БД изменение инфраструктуры? Нет. Изменятся ли организационные процессы в разработке, перераспределится ли нагрузка между разработчиками? Да. Вот что примерно я хотел бы услышать. Не очень понял мысль. Есть кнопка сохранения, которая, предположим, вызывает последовательно 3 процедуры, смотрит код ошибки и фиксирует/откатывает изменения. Первая из них p_add, в которой проверяются входные параметры и тупо insert into table. Если я оберну эти 3 процедуры процедурой p_save_button в которой будет контроль исключений и TCL, то просто добавится процедура на 30 строк, в остальном ничего не изменится, нет никаких 100500 процедур на все случаи жизни. |
Re: Светлая и темная сторона транзакций | |
---|---|
Владимир Максимов Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Что вкладывается в понятие "контроль транзакции"?
1. Если было начало транзакции, то обязательно должно быть завершение транзакции 2. Если было прерывание транзакции из-за исключительной ситуации, то 2.1. Выполняется откат транзакции (до какого уровня?) 2.2. Выполняется переход в программном коде (куда?) Предположим, мы переносим управление транзакции на уровень базы данных. Т.е. мы должны каким-то образом решить все эти поставленные вопросы Ну, инструменты для отслеживания уровня вложенности транзакции в базе данных должны быть. Т.е. п.1 решить можно. Откат транзакций в случае исключений - тоже должен быть предусмотрен в базе данных. И до какого уровня вложенности транзакции будет этот откат описано в документации А вот с тем, как должно прореагировать само приложение на этот откат - проблема. База данных ведь ничего не знает о самом приложении. Она с данными работает. Более того, здесь должна база данных неким образом начать "рулить" приложением. Напрямую дать команду приложению перейти на выполнение определенных строк кода. Я как-то смутно себе представляю как это можно сделать... В самом приложении логика понятная try (...) catch (...) Внутри try и catch может быть обращение к базе данных. Обратились к базе данных, получили ответ и по этому ответу дальше работаем Но если мы "смотрим" со стороны базы данных, то как? Как заставить приложение что-то там начать выполнять в случае ошибки в базе данных? Лично я вижу только дублирование управления. Все тот же try..catch со стороны приложения. Но если часть контроля невозможно убрать из приложения, то зачем усложнять систему делая, по сути, распределенный контроль (часть в приложении, часть в базе данных)? |
Re: Светлая и темная сторона транзакций | |
---|---|
PaulWist Сообщений: 14625 Дата регистрации: 01.04.2004 |
Что-то п.2.2 я не понял, какой переход в программном коде?Этот переход на клиенте или в БД? Транзакция должна завершиться или откатиться до того как будет передано управление на клиент, иначе мы получим кучу незакрытых транзакций удерживающих блокировки на объектах БД + паровоз очередей ожиданий.
Хммм, странный вопрос... проанализировать код возврата ХП, а дальше приложение решает само в какой программный модуль идти. Кстати, об этом Pekpytep пишет, что front-end открывает клиентскую транзакцию или даже не делает этого, а в режиме автокоммита просто "дергает" несколько ХП/ф-ий/команд подряд и не смотрит на код ошибки считая, что батч выполнился успешно. Если по дороге что-то сработало с ошибкой, то front-end не обращает внимание и коммитит транзакцию, получая не консистентные данные в бизнес логике. Поэтому, ТС хочет перенести код сохранения в ХП реализующую логику происходящую на клиенте, что бы избежать таких косяков.
Хммм, вот же слова дающие ответ:
Какой распределенный контороль? В ХП try (...) catch (...), те СУБД обрабатывает СВОИ ОШИБКИ, клиент обрабатывает свои ошибки, от БД клиент обрабатывает коды/сообщения возврата. ------------------ Есть многое на свете, друг Горацио... Что и не снилось нашим мудрецам. (В.Шекспир Гамлет) Исправлено 1 раз(а). Последнее : PaulWist, 28.05.20 18:17 |
Re: Светлая и темная сторона транзакций | |
---|---|
Гулин Федор Сообщений: 4640 Откуда: Минск Дата регистрации: 24.10.2002 |
@Игорь плз обоснуй выделенное на практических твоих примерах на прошлой работе 2 звенка апликухи из дельфи дергали T-sql SP на БД ( по факту там получался микс - ибо в SP часто передавали ) но логика вся (95%)сидела именно в SP ЗЫ вопрос коненчо интресный т.е когда я писал на фоксе к-й хорошо знал мен было удобней логику на клиенте когда я выучил t-sql - теперь мне удобней там (хотя язык конечно ограниченный и сильно) опять же - одно дело когда идут прямые запросы в БД а ля sql exec другое дело - их генерит какой-то фреймворк - о тут ПЕСНЯ может быть сразу вместо одного запроса на 1000 записей - он грубо говоря сгенерит 1000 PS @Рекрутер - МОЛОДЦА - давно не было на проф. тему обсуждений как-то выродился форум аж обидно - а так смотришь еще все таки можно обсудить чего-то по профессии не только треп. Исправлено 2 раз(а). Последнее : Гулин Федор, 28.05.20 18:29 |
Re: Светлая и темная сторона транзакций | |
---|---|
Гулин Федор Сообщений: 4640 Откуда: Минск Дата регистрации: 24.10.2002 |
это как бы оффтоп - но мне интересно - думаю может еще кому с а) ок - допустим решили и делаем так. б) - имеется ввиду ОДНА мастер SP для сохранения данных - одна в принципе вообще ?? и пример (я надеюсь в T-sql) наименования , Параметров , и пример вызова мне не очень понятна универсальность и как это реально может работать про в) я честно тоже не понял - можно сюда же всунуть в ответ пример чего и как. Исправлено 1 раз(а). Последнее : Гулин Федор, 28.05.20 18:36 |
Re: Светлая и темная сторона транзакций | |
---|---|
Божья_коровка Сообщений: 25731 Дата регистрации: 23.08.2001 |
Тоже немного не поняла про одну мастер ХП-шку. Вот к примеру, рисую я большой трехэтажный отчет и всю его логику расчета колонок запихиваю в одну ХПшку (функцию), потом просто дергаю эту функцию с разными параметрами и она формирует циферки, в общем то весь отчет заполняется этой мега-ХПшкой. Это и есть одна мастер ХПшка? ------------------ Жись, она как зёбра, полоса белая, полоса черная, а мне всегда задница достается... Исправлено 3 раз(а). Последнее : Божья_коровка, 28.05.20 18:56 |
Re: Светлая и темная сторона транзакций | |
---|---|
Божья_коровка Сообщений: 25731 Дата регистрации: 23.08.2001 |
Особенно полезно почитать, чего пишут умные люди ------------------ Жись, она как зёбра, полоса белая, полоса черная, а мне всегда задница достается... Исправлено 1 раз(а). Последнее : Божья_коровка, 28.05.20 18:59 |
Re: Светлая и темная сторона транзакций | |
---|---|
WbrErr Сообщений: 1960 Дата регистрации: 05.12.2006 |
Я вообще не понимаю, почему эта тема в курилке.
|
Re: Светлая и темная сторона транзакций | |
---|---|
Божья_коровка Сообщений: 25731 Дата регистрации: 23.08.2001 |
Скорее всего потому что автор не работает с фоксом уже давно. Pekpytep ораклист, плюс он дал такое "философское" наименование темы, что оно не подходит для проф.топика. Можно было тему закинуть в топик - Не фоксом единым, но там проходимость низкая. В Курилке больше людей слоняются без дела чтобы поболтать. Видимо из этих соображений автор и поместил сюда тему. ------------------ Жись, она как зёбра, полоса белая, полоса черная, а мне всегда задница достается... Исправлено 3 раз(а). Последнее : Божья_коровка, 28.05.20 19:06 |
Re: Светлая и темная сторона транзакций | |
---|---|
Pekpytep Автор Сообщений: 727 Откуда: Луганск Дата регистрации: 19.10.2010 |
Под контролем транзакции я вкладывал исключительно смысл TCL - savepoint to/commit/rollback включая неявные транзакции. Да, Паша правильно уловил суть, но похоже не все поняли о чем речь. Давайте еще раз подробнее объясню. Мое знание джавы недостаточно чтобы однозначно сказать как и что оно у них там происходит, но должно происходить примерно следующее: 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. показать окно с ошибкой или успехом Да, и здесь можно передать чушь в параметры, но теперь возможностей накосячить меньше и на стороне бд больше возможностей быстро найти и ликвидировать ошибку. Да, это выходит за рамки классической теории трехзвенки, но тут "либо шашечки, либо ехать". Потому что я тут усиленно игнорирую теории, нарушаю парадигмы и несу ересь. На серьезное обсуждение не тянет. |
Re: Светлая и темная сторона транзакций | |
---|---|
Pekpytep Автор Сообщений: 727 Откуда: Луганск Дата регистрации: 19.10.2010 |
Ну нет же, одной мегауниверсальной функцией здесь не обойтись, ибо логика на кнопке сохранения при создании некоего документа и, скажем, кнопки пересчета остатков единиц материальных ценностей все же дергает разные комбинации процедур. Имеется в виду скорее процедура-контейнер на бизнес-действие. И да, их будет несколько десятков. |
© 2000-2024 Fox Club  |