Фундаментальный вопрос о правильном использовании транзакций.

← →
Курдль © (2004-05-13 15:32) [40]

А! Сорри! Это про пример их хэлпа!

← →
Vlad © (2004-05-13 15:34) [41]

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

:-)

← →
Курдль © (2004-05-13 15:35) [42]

Я его привел только как пример изящного обхода проблем с внешними ключами. На самом деле ApplyUpdates вызывается в конце бизнесс-процесса "ввод данных" преимущественно по команде юзера.
Например при закрытии по "Ок" модальной формы ввода или кнопкой "Сохранить" над гридом.

← →
Vlad © (2004-05-13 15:47) [43]

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

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

← →
Petr V. Abramov © (2004-05-13 16:06) [44]

> у меня сложилась стойкая ассоциация, что транзакция, это такая
> большая ручка от чемодана, которую прилепляют к
> багажнику "Жигулей", чтобы они ездили, как "Феррари"

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

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

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

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

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

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

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

← →
kaif © (2004-05-13 16:09) [45]

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

← →
Курдль © (2004-05-13 16:27) [46]

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

Так я именно о том, что первый раз купив себе машину, причем рындван от ВАЗ, не следует первым делом ставить на нее спойлер! Не поедет ОНО как Порш, хоть обос...сь!
Мысль о подобном топике возникала у меня время от времени, глядя на подобные образцы: http://delphimaster.net/view/3-1084428403/

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

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

← →
Vlad © (2004-05-13 16:35) [47]

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

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

← →
Курдль © (2004-05-13 16:37) [48]

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

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

← →
Petr V. Abramov © (2004-05-13 16:45) [49]

> типа Оракла < ... > вообще ничего не блокирует!
Возьмите свои слова обратно, пока не Вас не накрыла буря эмоций. :) "Типа" может и не блокирует, а у Oracle с этим все ОК.
Об этом прям в первой книжке "Database Concepts" Part VII
"Data Protection" явно написано.

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

← →
Курдль © (2004-05-13 16:52) [50]

А коротко можно о том, что блокирует оракл без спец. команды типа LOCK TABLE ... или ... FOR UPDATE?

← →
Petr V. Abramov © (2004-05-13 17:17) [51]

Cделайте update и посмотрите v$lock и v$locked_object, найдите отличия от результата select ... for update.
Если заинтресуетесь, расскажу где почитать, какие вообще блокировки бывают и откуда берутся :)

← →
Курдль © (2004-05-13 17:21) [52]

Оч. интересно. Расскажите, плз, где почитать.
Я и вправду так глубоко не копал. Только мне интересно, как это сказывается на работе клиента?

> Я и вправду так глубоко не копал.
А вот это на работе клиента может сказатся плачевно. В виде повисаний из-за ожидания освобождения блокировки или, еще хуже, "развала" данных из-за неустановки ее где надо. Почитайте обсуждение Allegro в "Потрепаться", там есть простой и наглядный пример.

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

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

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).

А лучше ICQ

Фундаментальный вопрос о правильном использовании транзакций. Найти похожие ветки