Мастера 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 строк.

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

Vlad (2004-05-13 12:23:00) [41]

> Курдль © (13.05.04 12:17) [15]

> самый оптимальный вариант организации обмена данными с БД.

Так ты почитай заголовок своей ветки, а так же то, что ты писал про "манифесты о транзакциях"
Как это вяжется вот с этим:
> моё личное убеждение, что связка "кэшированные изменения
> + неявная транзакция по ApplyUpdates" - самый оптимальный
> вариант организации обмена данными с БД

Ты определись, о чем ты говоришь - об оптимальном обмене данными с БД или все-таки конкретно о работе с транзакциями ?

Кстати, если уж на то пошло, то связка "кэшированные изменения + неявная транзакция по ApplyUpdates" - далеко не всегда оптимальный вариант обмена данными

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

> А тут получается, что коммит выполняется независимо от этой
> настройки ? Как это понимать ?

Как раз в [*] говорится про то, Commit автоматом вызывается лишь при SHARED AUTOCOMMIT.

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

> Johnmen © (13.05.04 11:40) [10]
> И что ? Ты не слышишь или не понимаешь, что говорят ? М.б.
> так понятней (в твоём стиле):

Давай конструктивнее! Что именно не соответствует моим постулатам? В родном хэлпе и, напр., в книге "Делфи и приложения БД" (с) Шумаков П.В. [*] написано одно и то же про транзакции и кэшированные изменения (это к вопросу: " Ну опять же... Какое отношение имеет кеширование к управлению транзакциями ?").

> Vlad © (13.05.04 11:44) [12]
> По поводу кэшированных изменений.
> Судя по всему, ты говоришь только о работе с InterBase и
> компонентами IBX(FIB).

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

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

> Johnmen © (13.05.04 11:51) [13]

Да, я тут глянул BDE-шный метод ApplyUpdates также вызывает Commit транзакции.
Но правда это не дает повода обсуждать правильную работу с транзакциями и приплетать сюда кэшированные изменения.
В случае с БДЕ мне неясно другое. Ведь в БДЕ-алиасе есть явная настройка коммитов, т.е. можно указать - делать коммит автоматически или оставить его на совести разработчика.
А тут получается, что коммит выполняется независимоот этой настройки ? Как это понимать ?

Johnmen (2004-05-13 11:51:00) [45]
>Vlad © (13.05.04 11:44) [12]
>Судя по всему, ты говоришь только о работе с InterBase и
>компонентами IBX(FIB).

А вот судя по выдернотому им тексту из хелпа - BDE
:)))

Vlad (2004-05-13 11:44:00) [46]

> Курдль © (13.05.04 11:37) [9]

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

Соловьев (2004-05-13 11:41:00) [47]

> А что будет с документами Ворда, книгами Ёкселя, моделями
> Дизайнера и т.п.?

Это тут причем?
Мы же про БД разговариваем? Если ты транзакцию подтвердил, то данные уже физ. записаны на серваке, а кеш? кеш в памяти - и кранты... Пользователи в шоке - пол дня в урну :) А ты получишь по голове.

Johnmen (2004-05-13 11:40:00) [48]
И что ? Ты не слышишь или не понимаешь, что говорят ? М.б. так понятней (в твоём стиле):

Writes a dataset’s pending cached updates to the database. procedure ApplyUpdates; Description Call ApplyUpdates to write a dataset’s pending cached updates to a database. This method passes cached data to the database for storage, but the changes are not committed to the database. An application must explicitly call the database component’s Commit method to commit the changes to the database if the write is successful, or call the database’s Rollback method to undo the changes if there is an error. Following a successful write to the database, and following a successful call to the database’s Commit method, an application should call the CommitUpdates method to clear the cached update buffer. Note: The preferred method for updating datasets is to call a database component’s ApplyUpdates method rather than to call each individual dataset’s ApplyUpdates method. The database component’s ApplyUpdates method takes care of committing and rolling back transactions and clearing the cache when the operation is successful.

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

> Что будет с твоими кешированными изменениями, если допустим
> комп погаснет?

А что будет с документами Ворда, книгами Ёкселя, моделями Дизайнера и т.п.?
Кроме того, я давно не писал прог, где юзерам дается возможность сидеть и колбасить целые таблицы - все строго на формах ввода.
Одна запись - одно формализованное окно.

Соловьев (2004-05-13 11:32:00) [50]

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

перешел с Фокса наверное? Транзакции не для скорости, а для правильности :)

Что будет с твоими кешированными изменениями, если допустим комп погаснет?

Курдль (2004-05-13 11:32:00) [51]
Posts pending cached updates for specified datasets to the database server.

procedure ApplyUpdates(const DataSets: array ofTDBDataSet);

Description

Call ApplyUpdates to post pending cached updates for a specific set of open datasets to the database server. ApplyUpdates is only meaningful if the CachedUpdates property of a specified dataset is True.

DataSets is a list of dataset names specifying the datasets for which to post pending updates. DataSets need not list every currently open dataset. For each listed dataset ApplyUpdates calls the dataset’s ApplyUpdates and CommitUpdates methods to post that dataset’s pending cached updates.

Applying updates is a two-phase process that takes place within the context of the database component’s transaction control. When an application calls ApplyUpdates, the following events take place:

1 A database transaction starts.
2 Cached updates are written to the database (Phase 1).

If the database write is successful:

1 Database changes are committed, ending the transaction.
2 Cached updates are committed, clearing the internal cache buffer (Phase 2).

If the database write fails database changes are rolled back, ending the transaction.

The two-phased approach allows for effective error recovery, especially when updating multiple and interrelated datasets (for example, the datasets associated with a master/detail form).

Johnmen (2004-05-13 11:25:00) [52]
>Курдль ©

Ну опять же... Какое отношение имеет кеширование к управлению транзакциями ?

>В 90% случаев не пользуюсь явными транзакциями, а просто делаю ApplyUpdates.

Опять же. ApplyUpdates это конкретный метод конкретного класса. Для одного - это одно, для др. - другое. Причем он здесь ?

>Хотелось бы посмотреть ...

Вот из одного проекта (по поводу обращения с кешированными изменениями)

... with ...,pFIBDSReceiptsDetailR do begin; ... if pFIBDSReceiptsR.State in dsEditModes then pFIBDSReceiptsR.Post; UpdateTransaction.StartTransaction; try pFIBDSReceiptsR.ApplyUpdToBase; ApplyUpdToBase; UpdateTransaction.Commit; pFIBDSReceiptsR.CommitUpdToCach; CommitUpdToCach; ... except UpdateTransaction.Rollback; pFIBDSReceiptsR.CancelUpdates; CancelUpdates; ShowDlgMssg(Error,'Изменения не могут быть приняты !'); end; ...

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

> На эти события вешаются не только commit'ы. Так что говорить
> о том, что НИКАКИХ КОДОВ я бы не стал.

Это я в сердцах о коде из http://www.delphimaster.ru/cgi-bin/forum.pl?id=1084428403&n=1

bushmen (2004-05-13 11:14:00) [54]
>И никаких кодов для "onPost/onInsert"
На эти события вешаются не только commit'ы. Так что говорить о том, что НИКАКИХ КОДОВ я бы не стал.

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

> Работа в связке Client - BDE - DB2.

К сожалению, ничего не могу сказать про BDE, т.к. политика фирм, в которых я работал на протяжении долгих лет, категорически запрещала их использование.

Курдль (2004-05-13 11:08:00) [56]
Вот общий для IB, MSSQL, Sybase, Oracle (проверенный) код фиксации изменений, для наглядности выполненный на компонентах, надежно поддерживающих связь с перечисленными БД через ODBC:
procedure TForm1.SaveData; begin try SDQuery1.CheckBrowseMode; DB.ApplyUpdates([SDQuery1]); except on E: EDataBaseError do Application.MessageBox(PChar(E.Message), 'Ошибка записи', MB_ICONSTOP); end; end;
Вот и все! И никаких кодов для "onPost/onInsert" и т.п.
Хотелось бы посмотреть аналоги этого кода для других компонентов, например от мастеров IB-компонентов.

asp (2004-05-13 10:54:00) [57]
С пунктом 3 у меня возникали сложности с тем, что BDE оставляло курсоры открытыми, что в многопользовательском режиме не есть хорошо. Другого способа как объявить явную транзакцию с параметром Database'а SQLPASSTHRU MODE=SHARED AUTOCOMMIT не нашел. (Возможно, мало искал.)
Работа в связке Client - BDE - DB2.

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

Наверх

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