Когда лучше подтверждать транзакции

← →
Тучудище (2005-06-29 15:06) [0]

Решил потихоньку осваивать IBX, в принципе все понятно с загадочным компонентом транзакция разобрался, одно только мне не совсем ясно наткнулся на статью в сети где четко и ясно написано что не стоит подтверждать транзакцию после добавления каждой новой записи(сбило с толку). Ув. мастера подскажите плиз, по какой логике надо действовать чтобы понять, когда ее нужно подтвердить...
Разберем пример обычного справочника
Пользователь добавил несколько запись
Вижу два варианта
1) Автоматическое подтверждение(Если после каждой вставки нельзя то когда)
2) Кнопка подтвердить транзакцию (сами знаете чем это грозит....)

← →
Zacho © (2005-06-29 15:08) [1]

Почитай статьи на http://www.ibase.ru

← →
Zacho © (2005-06-29 15:11) [2]

Тучудище (29.06.05 15:06)
1) Автоматическое подтверждение(Если после каждой вставки нельзя то когда)

Кстати, это самый разумный вариант. Именно после каждой модификации данных делать Commit. Естественно, при массовой модификации данных желательно делать по другому.

← →
Тучудище (2005-06-29 15:16) [3]

Кстати, это самый разумный вариант. Именно после каждой модификации данных делать Commit. Естественно, при массовой модификации данных желательно делать по другому.

При массовой вопросов нет! Смутило что нежелательно комитить после каждой записи

← →
Zacho © (2005-06-29 15:20) [4]

Тучудище (29.06.05 15:16) [3]

Это действительно самый разумный вариант. Естественно, что модификация данных при этом должна производиться в отдельной транзакции.
Почитай, например, http://www.ibase.ru/devinfo/ibx.htm

Тучудище (29.06.05 15:16) [3]
Смутило что нежелательно комитить после каждой записи
Кому "не желательно" ? В каких случаях ? Случаи разные бывают ...

← →
Anatoly Podgoretsky © (2005-06-29 15:22) [5]

Тучудище (29.06.05 15:16) [3]
Смутило что нежелательно комитить после каждой записи

И правильно смутило, по сути это не верно, транзакцию надо подтвержадать когда она закончена, а не когда накопится что-то.
Эти рекомендации не связаны с транзакциями как таковыми, а с какой то оптимизацией какого то процесса и к транзакциям отношения не имеют. Быстродействие это совсем другой логический процесс и соответственно другой вопрос!

← →
Тучудище (2005-06-29 15:24) [6]

Спасибо за ответы! они наставили меня на пусть истиный

← →
kaif © (2005-06-29 16:01) [7]

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

procedure TMyForm.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
begin
if ModifiedButton.Enabled then
case MassageDlg("Сохранить изменения в документе таком-то?",
mtConfirmation, [mbYes, mbNo, mbCancel], 0) of
mrYes: SaveChanges;
mrCancel: CanClose := False;
end;
end;

procedure TMyForm.SaveChanges;
begin
with MyDataSet do
if State in [dsEdit,dsInsert] then
Post;
MyDataSet.Transaction.Commit;
ModifiedButton.Enabled := False;
end;

Пользователям это видится логичным.

← →
Desdechado © (2005-06-29 19:37) [8]

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

← →
Anatoly Podgoretsky © (2005-06-29 20:09) [9]

kaif © (29.06.05 16:01) [7]
Так это и есть транзакция в ее прямом толковании а не в компьютерном, единое неделимое действие.

Например при массовом копировании существуют две ситуации, каждая запись не зависима от другой - соответственно транзакция на каждую запись. Второй случай все записи должны быть скопированы полностью, не докопирование одной записи ведет к нарушению целостности - транзакция все записи. Промежуточных вариантов быть не может, это нарущение целостности или неэффективность.
Представим себе для первого случая рекомендацию делать копирование в транзакции по 100000 записей, пускай на записи 99999 произошла какая либо проблема, все предыдущии 99998 пошли насмарку. Получаем не экономию времени (а об транзакционности просто и говорить не призодится все 100000 операций независимы друг от друга), а получаем резкую его потерю, ничем не обоснованную.
Недавно мы устанавливали у себя базу MSSQL, где был импорт из ФоксПро. Весь импорт был атомарен, нельзя было закачать неверную информацию. Благодаря транзакционности мы получили целостную базу, а в процессе импорта были обнаружены несколько недопустимых значений в оригинале.
Без единой транзакции мы бы имели не консистентную систему и долго бы искали где проблема. А так просто методом деления пополам иы проблемы быстро обнаружили и устранили. В новой базе недопустимые значения уже появиться не могут.

← →
msguns © (2005-06-30 09:47) [10]

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

← →
Sergey13 © (2005-06-30 09:57) [11]

2[10] msguns © (30.06.05 09:47)
> лучше всего
Лучше чем что? Насколько лучше? 8-)

← →
msguns © (2005-06-30 10:27) [12]

>Sergey13 © (30.06.05 09:57) [11]

Хочется полялякать ? Я не против ;) Только эта.. давай в Потрепацца ;))

← →
Sergey13 © (2005-06-30 10:33) [13]

>Хочется полялякать ? Я не против ;)
Да не то что бы сильно хочется. Хоть и не против (с приятным человеком приятно полялакать). Я уже догадываюсь, что ты скажешь. А ты наверное догадываешься, что я отвечу. 8-)
Я ведь переспросил просто так. 8-)

>Только эта.. давай в Потрепацца ;))
Можно и туда. 8-)

← →
Игорь Шевченко © (2005-06-30 10:56) [14]

"Hе секрет, что rollback надо делать пореже,
Лучше делать почаще commit!
Я программой своей скоро сервер повешу -
У админа пускай голова поболит.

Под крики о кастрации,
В обкуренной прострации,
Как следствие мутации
Рождается в момент
Rollback segment для маленькой,
Для маленькой такой транзакции,
Для скромной такой транзакции
Огромный такой сегмент!

Hе секрет, что rollback - это язва и грыжа,
Геморрой и чуть-чуть гайморит.
Если ты программист, а не ослик бесстыжий -
Лучше делай почаще commit!

Припев.

Hе секрет, что друзьям тоже надо ресурсы,
Hадо память, процессор и диск...
Так что делай commit, а иначе... ты в курсе,
Что rollback - для тебя неоправданный риск.

Припев. "

← →
msguns © (2005-06-30 11:11) [15]

Супер !!!
Сам придумал ?

← →
Игорь Шевченко © (2005-06-30 11:44) [16]

msguns © (30.06.05 11:11) [15]

Нет конечно. Изначально в fido увидел, потом в инете нашел :)

← →
Val © (2005-06-30 12:00) [17]

кстати, в песенке довольно вредный совет о необходимости частых коммитов в оракле.

← →
Игорь Шевченко © (2005-06-30 12:09) [18]

Val © (30.06.05 12:00) [17]

Кстати да.

← →
Sergey13 © (2005-06-30 12:13) [19]

2[17] Val © (30.06.05 12:00)
Ну, если "частых"="ненужных", то да. Иначе почему вредный?

← →
Digitman © (2005-06-30 12:17) [20]

> Когда лучше подтверждать транзакции

тогда когда нужно подтвердить перевод БД из одного устойчивого состояния в другое

а уж что конкретно входит в "устойчивое состояние" - состояние до/после вставки/модификации/удаления одной ли единственной записи либо вставки/модификации/удаления более чем одной записи в более чем одной таблицах - это определять тебе как разработчику

← →
Игорь Шевченко © (2005-06-30 12:24) [21]

Sergey13 © (30.06.05 12:13) [19]

> Иначе почему вредный?

потому что возможно появление сообщения "Snapshot too old"

← →
Sergey13 © (2005-06-30 12:34) [22]

2[21] Игорь Шевченко © (30.06.05 12:24)
Все таки надо уточнить критерии "частости" и "полезности", ИМХО.
Понятно, что при вставке/апдейте 1000 записей комитить каждую глупо. А если в гриде менять записи, то по твоему надо после каждой комитить или нет? Я думаю, что надо. Это часто?

← →
Игорь Шевченко © (2005-06-30 12:39) [23]

Sergey13 © (30.06.05 12:34) [22]

Не стоит оперировать критериями "часто/нечасто", стоит оперировать критериями "одно согласованное состояние/другое согласованное состояние", с учетом ситуации возникновения ошибки. Например, если при вставке миллиона записей произошла ошибка, то имеют ли логический смысл вставленные 500 тысяч записей, или смысл имеет ситуация "или весь миллион или ничего".

← →
Sergey13 © (2005-06-30 12:42) [24]

2 [23] Игорь Шевченко © (30.06.05 12:39)
>Не стоит оперировать критериями "часто/нечасто"

Так и я к тому веду. Комитить надо по мере необходимости (с учетом технических возможностей разумеется), а не часто/редко.

← →
Игорь Шевченко © (2005-06-30 12:51) [25]

> Комитить надо по мере необходимости (с учетом технических
> возможностей разумеется),

Так об этом и речь, собстна. Необходимость каждый программист может понимать по-разному :)

← →
Val © (2005-06-30 12:59) [26]

>[19] Sergey13 © (30.06.05 12:13)
Естественно речь о ненужных. Потому что, некоторые товарищи, считают, что при вставке большого кол-ва записей, они получат выигрыш в скорости при нескольких подтверждениях, а не одном, после всей вставки. Кстати, об этом неплохо написано у того же Тома Кайта, с примерами, тестами и т.д.

← →
Игорь Шевченко © (2005-06-30 13:06) [27]

Sergey13 © (30.06.05 12:42) [24]

Собственно, кое-что есть здесь

http://www.relcom.ru:8080/scripts/ShowArticle.cgi?g=/relcom/comp/dbms/oracle/&a=8776

А у Кайта действительно неплохо написано.

← →
Desdechado © (2005-06-30 13:18) [28]

хм, а причем тут Оракл?
Транзакция - она и на оракле транзакция.
Другое дело, что в разных СУБД она с разными нюансами реализована. Но тогда см. у автора топика - у него IB, туда и комментируйте.

← →
Val © (2005-06-30 13:21) [29]

> [28] Desdechado © (30.06.05 13:18)
при песенке :)
ему уже накомментировали. теперь просто разболтались.

← →
msguns © (2005-06-30 13:27) [30]

>Digitman © (30.06.05 12:17) [20]
>а уж что конкретно входит в "устойчивое состояние" - состояние до/после вставки/модификации/удаления одной ли единственной записи либо вставки/модификации/удаления более чем одной записи в более чем одной таблицах - это определять тебе как разработчику

Вообще-то для "групповух" придумали хранимки и триггера.

Я бы ВСЕ операции над данными разделил на 3 большие логические (в плане перевода БД из одного завершенного/целостного состояния в другое) группы:

1. Одиночные. Пример: справочники, заголовки документов, "логовые" таблицы и т.д. Т.е. объектом одного целостного изменения (транзакции) является одна единственная запись одной таблицы.

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

3. Групповые (каскадные). Проводка/откат одного или группы сложных документов (типа накладных или лицевых счетов), когда в нескольких (иногда в десятке и даже более) таблицах меняется произвольное кол-во записей. При этом должны быть выполнениы либо ВСЕ измения, либо НИ ОДНОГО.

Во 2, а особенно в 3-м случае апдэйты следует заворачивать в ХП (или в триггера, как кому больше по душе), в то время как в 1-м одиночный запрос вполне "укладывается" в рамки "клиентской" транзакции.

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

Существенное замечание.
Умышленно не затронута проблема кэширования изменений на клиенте, существенно влияющая на "политику" транзакций приложения.

Все - ИМХО ;))

← →
Digitman © (2005-06-30 13:31) [31]

> msguns © (30.06.05 13:27) [30]

> Вообще-то для "групповух" придумали хранимки и триггера

бесспорно.
но никто не напрягает использовать для "групповухи" искл-но серверную сторону, и на суть вопроса это тоже не влияет

← →
Игорь Шевченко © (2005-06-30 13:32) [32]

msguns © (30.06.05 13:27) [30]

> Во 2, а особенно в 3-м случае апдэйты следует заворачивать
> в ХП (или в триггера, как кому больше по душе), в то время
> как в 1-м одиночный запрос вполне "укладывается" в рамки
> "клиентской" транзакции.

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

← →
Андрей Жук © (2005-06-30 13:48) [33]

Сколько нужно, столько и передавать. А шо, жалко? Зато быстрее

← →
msguns © (2005-06-30 13:59) [34]

>Игорь Шевченко © (30.06.05 13:32) [32]
>Честно говоря, не понимаю, почему надо заворачивать. Это ж сколько параметров надо передать в процедуру, если планируется изменение множества записей во множестве таблиц ?

"Надо" - это не то слово, которое уместно во всех случаях. Я же написал во-первых, про имхо, а во-вторых, про искусство ;))

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

← →
Игорь Шевченко © (2005-06-30 14:23) [35]

msguns © (30.06.05 13:59) [34]

Вах. Я не знаю понятия "приход в складских системах" в теории баз данных. Давай о терминологии договоримся.

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

← →
msguns © (2005-06-30 14:41) [36]

>Игорь Шевченко © (30.06.05 14:23) [35]
>Вах. Я не знаю понятия "приход в складских системах" в теории баз данных. Давай о терминологии договоримся.

Складские системы приведены как пример. Не нравится склад, возьми расчет з/пл для подразделения. Или расчет угла атаки для аивиапушки. Какая разница-то ?

> Но для того, чтобы данные в этот десяток таблиц запихнуть посредством процедуры, очевидно, стоит в процедуру передать их, не так ли ?

Передать в процедуру ID удаляемого документа или TDataTime стартового в группе проблема ?
Теперь я не понял ;(

← →
Игорь Шевченко © (2005-06-30 14:52) [37]

msguns © (30.06.05 14:41) [36]

>
> Передать в процедуру ID удаляемого документа или TDataTime
> стартового в группе проблема ?

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

← →
msguns © (2005-06-30 15:26) [38]

>Игорь Шевченко © (30.06.05 14:52) [37]
>Я наверное тебя не так понял. Я думал, ты имеешь в виду, что вставка данных для такой транзакции тоже должна быть обернута в процедуру. А удалить проблем нету, обычно в триггере.

Откатить - это вовсе не удалить ! В триггер нельзя, ибо если документ непроведенный, то любое его изменение НЕ приводит к изменению, например, текущих остатков. А если проведенный, то приводит. Но это так, к слову.

← →
Sergey13 © (2005-06-30 15:54) [39]

2 msguns © & Игорь Шевченко ©
Похоже вы про разные откаты спорите. Один про откат документа другой про откат транзакции. Нет?
ЗЫ: Есть и еще значения у отката. 8-)

← →
Игорь Шевченко © (2005-06-30 16:01) [40]

msguns © (30.06.05 15:26) [38]

> если документ непроведенный, то любое его изменение НЕ приводит
> к изменению, например, текущих остатков. А если проведенный,
> то приводит. Но это так, к слову.

А давай я тебе про сэмплинг или про клиринговые методы взаимозачетов или про BSP с ARC чего-нибудь расскажу интересное и познавательное ?
Развелось бухгалтеров, понимаешь, плюнуть негде :)

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

> А давай я тебе про сэмплинг или про клиринговые методы взаимозачетов
> или про BSP с ARC чего-нибудь расскажу интересное и познавательное
> ?
- раскажи, раскажи ! Интересно. Никогда таких абревиатур не слышал. Хоть определение дай. Только давайте в потрепаться переедем.

msguns © (30.06.05 16:39) [44]

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

>Игорь Шевченко © (30.06.05 17:00) [45]
>Сережа, завязываем оффтопик

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

2 [46] msguns © (30.06.05 17:32)
Удобство запихивания все таки мало перекликается собственно с транзакциями и их подтверждением. 8-)

Могу привести пример, когда даже делая связанные между собой изменения в базе приходится каждое изменение в отдельности коммитить. Как ни прискорбно, но в IB желательно коммитить любое изменение метаданных (за редким исключением). А некоторые изменения требуют не только коммита, но и монопольного доступа и даже реконнекта после внесения изменения и коммита. У меня программа много и плотно работает с метаданными и я прошел все круги ада, пока выработал ряд правил работы с метаданными IB.
1. Если после изменения метаданных (например, после создания новой таблицы) нужно изменить какие-то данные (например, вставить имя только что созданной таблицы в виде записи в какую-то свою "системную" таблицу), то необходимо эти действия делать в разных транзакциях и DDL-транзакцию (изменение метаданных) коммитить перед вставкой (DML-транзакцией).
2. До и после создания или удаления FOREIGN KEY нужно реконнектиться, иначе можно попасть в ситуацию "Table is in use" или "Index is in use".
3. Хранимые процедуры можно создавать/удалять безболезненно даже когда с системой работают пользователи.
4. Хранимые процедуры можно даже создать, использовать и уничтожить в пределах одной отдельной транзакции, не подтверждая ее.
5. Хранимые процедуры, вызываемые другими хранимыми процедурами могут продолжать работать в старых версиях даже после коммита транзакции, если не переконнектиться после изменения текста "вложенных процедур". Так что желательно избегать вложенности процедур или же тщательно разрабатывать "вложенные процедуры", чтобы часто не приходилось корректировать их текст.
6. Не использоать версии Firebird ниже 1.5 и InterBase ниже 6.5 и Yaffil ниже билда 877, если часто работаешь с метаданными.

2[48] kaif © (01.07.05 03:10)
>Как ни прискорбно, но в IB желательно коммитить любое изменение метаданных (за редким исключением).
А что тут прискорбного? В Оракле DDL вообще вызывает неявный коммит. Да и вообще работа с метаданными в прикладной программе "на лету" дело очень тонкое и нетривиальное. И в 90% случаев говорит о непродуманности структуры (я немного знаком с твоей работой поэтому сразу оговорюсь, что ты, скорее всего, попадаешь в оставшиеся проценты 8-).

Sergey13 © (01.07.05 09:22) [49]

> В Оракле DDL вообще вызывает неявный коммит

Не только в Oracle, но везде. Насколько я помню, это стандарт.

kaif © (01.07.05 03:10) [48]

> 6. Не использоать версии Firebird ниже 1.5 и InterBase
> ниже 6.5 и Yaffil ниже билда 877, если часто работаешь с
> метаданными

Э...странно. Я на Interbase 6.0.1 довольно неплохо себя чувствовал в похожей ситуации.

2 kaif
это не типичный пример, а исключение
транзакция в обычном понимании - это манипуляция с данными, а не метаданными
понятно, что большинство серверов хранит метаданные как данные в системных таблицах, но это их внутреннее дело
нам, как пользователям, больше интересны именно обычные данные и обычные транзакции с ними

2 Игорь Шевченко
Не стандарт, а стремление к нему. Как верно указал kaif, в IB/FB большинство изменений метаданных можно проводить в одной транзакции. И, честно говоря, мне это нравится больше. А вот затыки с FK раздражают в таком контексте.

> Не только в Oracle, но везде. Насколько я помню, это стандарт.

Вовсе нет.
Например, в MSSQL DDL и DML могут смешиваться в одной транзакции.

DiamondShark © (01.07.05 11:26) [52]

> Например, в MSSQL DDL и DML могут смешиваться в одной транзакции.

И при откате транзакции изменения, внесенные DDL-операторами тоже будут отменены ?

> И при откате транзакции изменения, внесенные DDL-операторами
> тоже будут отменены ?

Да.

begin transaction create table Zzz(Id INT, Name CHAR(10)) insert into Zzz values(1,"qweqweqwe") select * from Zzz rollback transaction select * from Zzz (1 row(s) affected) Id Name ----------- ---------- 1 qweqweqwe (1 row(s) affected) Server: Msg 208, Level 16, State 1, Line 1 Invalid object name "Zzz".

>kaif © (01.07.05 03:10) [48]

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

Когда лучше подтверждать транзакции Найти похожие ветки