Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Delphi: Базы данных и репортинг > Commit и CommitRetaining


Автор: Delphist 13.3.2008, 09:54
У меня возник вопрос, можно ли сказать, что с позиции СУБД

FIBQuery.Transaction.CommitRetaining

это тоже самое, что

FIBQuery.Transaction.Commit;
FIBQuery.Open;

Автор: Deniz 13.3.2008, 11:53
FIBQuery для СУБД вообще по барабану.
CommitRetaining и Commit, можно сказать, с некоторой оговоркой, одно и то же.

Автор: TObject 13.3.2008, 14:57
CommitRetaining - подтверждает сделанные изменения, но не закрывает НД - тоесть не нужно тянуть снова данные на клиент, а при Commit приходится переоткрывать НД, так что это не одно и тоже.

Автор: Deniz 13.3.2008, 15:33
TObject, ну и расскажи чем так они сильно отличаются
Цитата(Delphist @  13.3.2008,  12:54 Найти цитируемый пост)
с позиции СУБД

Про то как это работает с клиента я уже говорил в http://forum.vingrad.ru/forum/topic-180633.html ветке и не стал повторяться

Автор: TObject 13.3.2008, 16:03
Цитата(Deniz @ 13.3.2008,  15:33)
TObject, ну и расскажи чем так они сильно отличаются
Цитата(Delphist @  13.3.2008,  12:54 Найти цитируемый пост)
с позиции СУБД

Цитата

"...Короткую транзакцию не нужно завершать CommitRetaining. На самом деле CommitRetaining просто продлевает жизнь транзакции, а соответственно из "короткой" превращает ее в длинную. То есть, для сервера завершение по CommitRetaining будет сохранять все те побочные эффекты, которые вызываются длинными транзакциями..."
 - это не разница?

Взято с http://www.ibase.ru

Автор: Delphist 13.3.2008, 16:47
Цитата(TObject @  13.3.2008,  17:03 Найти цитируемый пост)
для сервера завершение по CommitRetaining будет сохранять все те побочные эффекты, которые вызываются длинными транзакциями..."

И что это за побочные эффекты?

Автор: TObject 13.3.2008, 17:09
Цитата(Delphist @ 13.3.2008,  16:47)
И что это за побочные эффекты?

Цитата
...Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log. Кроме того, транзакция, завершаемая по CommitRetaining, с точки зрения сервера и сборки мусора выглядит как длительно работающая транзакция SNAPSHOT (то есть, CommitRetaining в этом плане не является аналогом Commit). А это значит, что CommitRetaining фактически препятствует сборке мусора, независимо от типа транзакции - Snapshot или ReadCommitted... 
 http://www.ibase.ru

Автор: Akella 13.3.2008, 17:33
я лично вообще не использую CommitRetaining

Автор: Delphist 13.3.2008, 17:51
Я так и ничего не понял, чем плоха CommitRetaining
Вот пользователь в нес изменения затем нажимаем кнопку сохранить по которой срабатывает CommitRetaining т.е. как я понимаю в БД произойдет Commit + на клиентскую часть пересылаются все обновления, тогда как простой Commit , вызовет на сервер коммит, но обновления (имеется ввиду обновления которые закоммитили другие пользователи за время, пока вносил изменения мой пользователь) на клиентскую часть не предут, и в что же, тогда плохого в CommitRetaining

Автор: TObject 13.3.2008, 18:35
Цитата(Delphist @ 13.3.2008,  17:51)
Вот пользователь в нес изменения затем нажимаем кнопку сохранить по которой срабатывает CommitRetaining т.е. как я понимаю в БД произойдет Commit + на клиентскую часть пересылаются все обновления,
 Не все обновления, а только те что сделаны этой таранзакцией, если другие пользователи будут редактировать эту же таблицу то изменений не будет видно пока не переоткрыть НД. Тогда как при простом Commit НД прийдется переоткрыть и будет видно все изменения которое были сделаны другими пользователями.

Автор: Delphist 13.3.2008, 19:38
Цитата(TObject @  13.3.2008,  19:35 Найти цитируемый пост)
Тогда как при простом Commit НД прийдется переоткрыть и будет видно все изменения которое были сделаны другими пользователями. 

Что-т я так и не понял по твоим словам получается, что необходимо переоткрывать НД и при CommitRetaining'e и при Commit'e

Автор: TObject 14.3.2008, 09:44
Цитата(Delphist @ 13.3.2008,  19:38)
Что-т я так и не понял по твоим словам получается, что необходимо переоткрывать НД и при CommitRetaining'e и при Commit'e

При CommitRetaining Ваш НД остается открытым, но Вы не видите изменения сделанные другими пользователями. 

При Commit НД закроется сам (по крайней мере у меня так) и его прийдется открыть по новой. соответсвенно видим все изменения.

Тоесть если нужно все время иметь свежие данные в НД, то прийдется переоткрывать в обеих случаях. 

Автор: Delphist 14.3.2008, 09:57
Цитата(TObject @  14.3.2008,  10:44 Найти цитируемый пост)
При CommitRetaining Ваш НД остается открытым, но Вы не видите изменения сделанные другими пользователями. 

При Commit НД закроется сам (по крайней мере у меня так) и его прийдется открыть по новой. соответсвенно видим все изменения.

И все же чем же плох CommitRetaining по отношению к Commit'y

Нашел вот эту цитату:
Код

...Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом
таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log. Кроме того,
транзакция, завершаемая по CommitRetaining, с точки зрения сервера и сборки мусора выглядит как длительно работающая
транзакция SNAPSHOT (то есть, CommitRetaining в этом плане не является аналогом Commit). А это значит, что
CommitRetaining фактически препятствует сборке мусора, независимо от типа транзакции - Snapshot или ReadCommitted... 


Но из нее я так и ничего непонял и что значит CommitRetaining фактически препятствует сборке мусора, а простой коммит что не препятствует, и каком вообще мусоре идет речь?

Автор: TObject 14.3.2008, 11:41
Цитата(Delphist @ 14.3.2008,  09:57)
Но из нее я так и ничего непонял и что значит CommitRetaining фактически препятствует сборке мусора, а простой коммит что не препятствует, и каком вообще мусоре идет речь?

"Мусор" - это старые версии записей (результат многоверсионности), а вообще-то вот статья, читайте: http://www.ibase.ru/devinfo/oitoat.htm и вообще там есть много чего по СУБД IB/FB

Автор: Deniz 14.3.2008, 11:54
Цитата(TObject @  13.3.2008,  19:03 Найти цитируемый пост)
 - это не разница?
согласен. +

http://www.ibase.ru/devinfo/ibtrans.htm

Цитата(Delphist @  14.3.2008,  12:57 Найти цитируемый пост)
Но из нее я так и ничего непонял и что значит CommitRetaining фактически препятствует сборке мусора, а простой коммит что не препятствует, и каком вообще мусоре идет речь?
не столько препятствует, сколько ...
для начала:
Цитата
Физически завершение транзакции по Retaining стартует новую транзакцию (если изменений в транзакции не было, то транзакция реально не завершается), но с сохранением контекста предыдущей. Для SNAPSHOT в контекст попадает локальная копия таблицы состояния транзакций, которая была сохранена в момент старта этой транзакции. В результате, сколько бы не выполнялось retain-завершений для snapshot, эта транзакция будет всегда видеть только те данные, которые существовали именно в момент ее старта, а не в момент retain-завершений. Для транзакций ReadCommitted committed-изменения других транзакций видны независимо от retain-завершения.
Из изложенного следует, что завершать snapshot-транзакции по retaining особого смысла не имеет, т.к. вероятность конфликтов тем выше, чем дольше длится snapshot-транзакция.
из этого имеем: если контекст транзакции не изменился, значит просто удерживаются версии записей(мусор) этой транзакции, сл-но только они и не попадут под сборку мусора. Мусор все равно соберется.

Автор: Delphist 14.3.2008, 13:00
Цитата(Deniz @  14.3.2008,  12:54 Найти цитируемый пост)
сл-но только они и не попадут под сборку мусора. Мусор все равно соберется. 

Какое-то противоречие

И еще если у меня транзакция в открыта режиме ReadCommited, то тогда получается что Commited и CommitedRetaining одно, а если в режиме snapshot, то тогда Commited и CommitedRetaining  не много разные вещи, правильно ли понял?

Автор: TObject 14.3.2008, 13:22
Цитата(Deniz @ 14.3.2008,  11:54)
Для транзакций ReadCommitted committed-изменения других транзакций видны независимо от retain-завершения.
Я это тоже читал, но тут или какая-то неточность или я делаю чтото не правильно, у меня транзакция ReadCommitted с параметрами:
Цитата
write
nowait
rec_version
read_committed

не видит изменения других транзакций, кроме своих, пока не переоткроется НД.

Автор: Deniz 14.3.2008, 13:42
Цитата(Delphist @  14.3.2008,  16:00 Найти цитируемый пост)
Какое-то противоречие
никакого противоречия нет.
Мусор появляется не только от одной транзакции.
Допустим стартанули 2 транзакции.
1. прочитала, потом добавила/обновила/удалила записи потом Commit.
2. прочитала, потом добавила/обновила/удалила записи потом CommitRetaining.
Так вот мусор от первой транзакции соберется, а от 2 нет.


Цитата(TObject @  14.3.2008,  16:22 Найти цитируемый пост)
не видит изменения других транзакций, кроме своих, пока не переоткроется НД. 
давайте определимся, для кого мы проверяем видимость? Для клиента или сервера?
Так вот для клиента(при CommitRetaining) НД не закрывается и показывается весь текущий локальный кеш для записей.
Новые данные поступят только после переоткрытия, сл-но если нужны правильные(новые) данные, то делать CommitRetaining + DataSet.Open нет никакого смысла, лучше CommiT + DataSet.Open.
И это логично, т.е. CommitRetaining подтверждает другим транзакциям, что данные изменились.

Автор: TObject 14.3.2008, 14:34
To Deniz: В предидущем посте Вы действительно написали не совсем понятно, может думали иначе. 

Цитата
Никакого противоречия нет.
Мусор появляется не только от одной транзакции.
Допустим стартанули 2 транзакции.
1. прочитала, потом добавила/обновила/удалила записи потом Commit.
2. прочитала, потом добавила/обновила/удалила записи потом CommitRetaining.
Так вот мусор от первой транзакции соберется, а от 2 нет.
А вот тут все понятно, я согласен.

Цитата
давайте определимся, для кого мы проверяем видимость? Для клиента или сервера?
Конечно же для клиента, сервер видит изминения в обеих случаях.

Автор: Deniz 14.3.2008, 15:51
Цитата(TObject @  14.3.2008,  17:34 Найти цитируемый пост)
Конечно же для клиента, сервер видит изминения в обеих случаях. 
а какие изменения можно увидеть на клиенте, не переоткрыв НД? Это же как отчет, напечатал смотришь, второй раз напечатал, смотришь новые данные.

Автор: TObject 14.3.2008, 16:08
Цитата(Deniz @ 14.3.2008,  15:51)
а какие изменения можно увидеть на клиенте, не переоткрыв НД? Это же как отчет, напечатал смотришь, второй раз напечатал, смотришь новые данные.

Я понимаю. Просто затупил на счет написаного в статье. Уже дошло. smile

Автор: Delphist 14.3.2008, 20:16
Цитата(Deniz @  14.3.2008,  14:42 Найти цитируемый пост)
Допустим стартанули 2 транзакции.
1. прочитала, потом добавила/обновила/удалила записи потом Commit.
2. прочитала, потом добавила/обновила/удалила записи потом CommitRetaining.
Так вот мусор от первой транзакции соберется, а от 2 нет.

А почему от второй не убирается мусор, ведь же CommitRetaining как бы содерджит в себе Commit, т.е. данные одназначно закомичены и откатить их нельзя, зачем тогда сервер сохраняет мусор (промежуточные изменения)?

Автор: CompWorm 14.3.2008, 23:07
да, интересная тема.
Цитата

зачем тогда сервер сохраняет мусор

это особенно интересно... 
и как бы его вычистить безболезненно))

Автор: TObject 15.3.2008, 01:46
Цитата
А почему от второй не убирается мусор, ведь же CommitRetaining как бы содерджит в себе Commit, т.е. данные одназначно закомичены и откатить их нельзя, зачем тогда сервер сохраняет мусор (промежуточные изменения)?

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

Цитата
и как бы его вычистить безболезненно))

Ну во-первых в сборке "мусора" участвует каждая транзакция, в том числе и read-only.
Во-вторых backup БД делает уборку "мусора".
В-третьих параметр sweep interval задает значение при достижении которого произойдет sweep.

Автор: CompWorm 15.3.2008, 12:30
TObject, спасибо

Автор: Deniz 17.3.2008, 06:19
Цитата(CompWorm @  15.3.2008,  02:07 Найти цитируемый пост)
и как бы его вычистить безболезненно)) 
делать COMMIT, а мусор сам соберется со временем, если только sweep interval > 0, если 0 мусор вообще собираться не будет

Автор: Delphist 17.3.2008, 10:22
Цитата(TObject @  15.3.2008,  02:46 Найти цитируемый пост)
транзакция которая подтерждена по CommitRetaining остается активной, а соответсвенно является "заинетесованной" 

Что значит "заинетесованной", не совсем понятно?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)