Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Фундаментальный вопрос о правильном использовании транзакций. [D6, Правильная БД]

Страницы: 1 2 3 >
Курдль © (2004-05-13 10:47:00)
После плодотворного общения на этом уважаемом форуме у меня сложилась стойкая ассоциация, что транзакция, это такая большая ручка от чемодана, которую прилепляют к багажнику "Жигулей", чтобы они ездили, как "Феррари" (еще ее называют спойлером).
Есть предложение раз и навсегда выработать общие рекомендации по работе с транзакциями и вынести результат куда-нить в ФАК.

У меня есть свой стиль, который я ни в коем случае никому не навязываю. Но очень хотел бы почитать всеобщую критическую оценку.

1. Я работаю только с кэшированными изменениями.
2. После работы с набором данных фиксирую обновления.
3. В 90% случаев не пользуюсь явными транзакциями, а просто делаю ApplyUpdates.
4. Пользуюсь явными транзакциями лишь в тех случаях, когда требуется откат изменений, сделанных во множественных таблицах со сложными связями.
5. Как правило код фиксации при такой работе занимает 5-10 строк.

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

Petr V. Abramov (2004-05-13 21:18:00) [1]
А лучше ICQ

Petr V. Abramov (2004-05-13 19:54:00) [2]
> kaif © (13.05.04 19:13) [55]
> Вы не будете возражать
Не буду :)

kaif (2004-05-13 19:13:00) [3]
2 Petr V. Abramov © (13.05.04 17:33) [53]
Кстати, насчет Allegro. Я обдумываю добавление и настройку ресурсов типа "критического склада" в Allegro, но у меня есть ряд вопросов, связанных с этой темой. В частности, какие ограничения я могу себе позволить наложить на юзеровв части редактирования документов "задним числом". Вы не будете возражать, если я напишу Вам на мейл?
Я хотел бы организовать такой ресурс на основе того, что IB не допускает подтверждения одновременного редактирования одной и той той же записи двумя юзерами, даже при изоляции ReadCommitted и nowait. Если сделать ресурс, работающий пои принципу:

update ... set quantity = quantity - :sale where id = :id

в коротких отдельных транзакциях на модификацию с предложением "повторить попытку" при "накладке", то пессимистическая задача решается корректно.
Я добавил в Allegro поддержку таких транзакций (вторая write-транзакция для IBX).

Курдль (2004-05-13 18:14:00) [4]

> Почитайте обсуждение Allegro в "Потрепаться", там есть простой
> и наглядный пример.

К сожалению, не нашел.

Petr V. Abramov (2004-05-13 17:33:00) [5]
> Я и вправду так глубоко не копал.
А вот это на работе клиента может сказатся плачевно. В виде повисаний из-за ожидания освобождения блокировки или, еще хуже, "развала" данных из-за неустановки ее где надо. Почитайте обсуждение Allegro в "Потрепаться", там есть простой и наглядный пример.

Курдль (2004-05-13 17:21:00) [6]
Оч. интересно. Расскажите, плз, где почитать.
Я и вправду так глубоко не копал. Только мне интересно, как это сказывается на работе клиента?

Petr V. Abramov (2004-05-13 17:17:00) [7]
Cделайте update и посмотрите v$lock и v$locked_object, найдите отличия от результата select ... for update.
Если заинтресуетесь, расскажу где почитать, какие вообще блокировки бывают и откуда берутся :)

Курдль (2004-05-13 16:52:00) [8]
А коротко можно о том, что блокирует оракл без спец. команды типа LOCK TABLE ... или ... FOR UPDATE?

Petr V. Abramov (2004-05-13 16:45:00) [9]
> типа Оракла < ... > вообще ничего не блокирует!
Возьмите свои слова обратно, пока не Вас не накрыла буря эмоций. :) "Типа" может и не блокирует, а у Oracle с этим все ОК.
Об этом прям в первой книжке "Database Concepts" Part VII
"Data Protection" явно написано.

> Просто не даст ничего лишнего, что могло бы навредить.
Будем считать не очень удачным переводом слова "How Oracle Locks Data" (из Database Concepts :)

Курдль (2004-05-13 16:37:00) [10]

> Да ну ?
> select * from table where ... for update // Выбрали, заблокировали
> commit; // сняли блокировку

Так это оракл блокирует, или юзер?

Vlad (2004-05-13 16:35:00) [11]

> Правильная СУБД, типа Оракла, с которой я больше всего работаю,
> вообще ничего не блокирует!

Да ну ?
select * from table where ... for update // Выбрали, заблокировали
commit; // сняли блокировку

Курдль (2004-05-13 16:27:00) [12]

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

Так я именно о том, что первый раз купив себе машину, причем рындван от ВАЗ, не следует первым делом ставить на нее спойлер! Не поедет ОНО как Порш, хоть обос...сь!
Мысль о подобном топике возникала у меня время от времени, глядя на подобные образцы: http://www.delphimaster.ru/cgi-bin/forum.pl?id=1084428403&n=1

> Правильная СУБД помогает в этом установкой блокировок и
> удержанием их до конца транзакции.

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

kaif (2004-05-13 16:09:00) [13]
Приведу аргумент в пользу явного управления вообще чем-либо. Вот, например, в паскале и в си управление типом переменных явное. А в интерпретаторах зачастую используется неявное управление типами переменных и, как следствие, изменение типов некоторых переменных "на ходу". Если здесь есть программисты, работавшие на интерпретаторах (я работал долго на FoxPro 2.6), то они не дадут соврать. Поиск и выявлении ошибок при неявном управлениии переменными иногда доводит до отчаяния... Никаких таких проблем не бывает априори в языках с жесткой типизацией. Хотя строк кода с виду больше. Аналогично, я подозреваю, дело обстоит и с транзакциями. Могу рассказать про мою личную "эволюцию". Когда я только начинал работать с IB, я использовал BDE и редко заморачивался на транзакции вообще. Затем я перешел на IBX и стал больше уделять этому внимание. Сейчас я абсолютно всетранзакции, если это не readonly транзакция стартую и подтверждаю явно. Во-первых, так мне легче видеть логику того, что я делаю в тексте программы, так как это находится в одном месте. Так мне легче обрабатывать все блоках try, если это нреобходимо.
Никаких преимуществ в неявном управлении транзакциями, кроме недостатков, на сегодня я не знаю.

Petr V. Abramov (2004-05-13 16:06:00) [14]
> у меня сложилась стойкая ассоциация, что транзакция, это такая
> большая ручка от чемодана, которую прилепляют к
> багажнику "Жигулей", чтобы они ездили, как "Феррари"

Скорее, "плюшевые кости на зеркале и корона на панели", чтобы все было как у людей :)

> У меня есть свой стиль, который я ни в коем случае никому не
> навязываю. Но очень хотел бы почитать всеобщую критическую
> оценку.

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

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

kaif © (13.05.04 12:57) [22]
> 3. Правильная организация транзакций обычно прежде всего
> преследует достижение правильной координации совместной работы
> множества юзеров с базой данных и поэтому сильно зависит от
> задачи.

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

> Различение транзакций на "явные" и "неявные" может не иметь
> никакого отношения к сущности самих этих транзакций и вызывать
> дополнительные недоразумения.
С точки зрения Правильной СУБД все транзакции явные. Различение транзакций на "явные" и "неявные" с моей точки зрения есть вредная глупость, наверное, призванная упростить жизнь фокпрошникам, но реально ВСЕМ ее усложняющая.

Vlad (2004-05-13 15:47:00) [15]

> Я его привел только как пример изящного обхода проблем с
> внешними ключами

А я тебе привел другой пример (на основе твоего же), когда ApplyUpdates может привести к нежелательным последствиям.
Так что, еще раз говорю, надежнее, когда транзакциями управляешь сам.

Курдль (2004-05-13 15:35:00) [16]
Я его привел только как пример изящного обхода проблем с внешними ключами. На самом деле ApplyUpdates вызывается в конце бизнесс-процесса "ввод данных" преимущественно по команде юзера.
Например при закрытии по "Ок" модальной формы ввода или кнопкой "Сохранить" над гридом.

Vlad (2004-05-13 15:34:00) [17]

> Да кто ж его туда вешает? Извращенцы, что ли??!!

:-)

Курдль (2004-05-13 15:32:00) [18]
А! Сорри! Это про пример их хэлпа!

Курдль (2004-05-13 15:30:00) [19]

> Если ты на BeforeClose детайл-датасета вешаешь ApplyUpdates([....]),
>

Да кто ж его туда вешает? Извращенцы, что ли??!!

Vlad (2004-05-13 15:24:00) [20]

> Курдль © (13.05.04 15:16) [37]

> в остальных СУБД транзакция жестко привязана к сессии, а
> не к датасэту.

> При кэшированных изменениях это приведет всего лишь к refresh-у
> датасэта.

При любых изменениях. Не только при кэшированных.
Если ты на BeforeClose детайл-датасета вешаешь ApplyUpdates([....]), то его закрытие/открытие приведет к коммиту транзакции
И что это правильно по-твоему ?

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »