Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > 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, ну и расскажи чем так они сильно отличаются Про то как это работает с клиента я уже говорил в http://forum.vingrad.ru/forum/topic-180633.html ветке и не стал повторяться |
Автор: TObject 13.3.2008, 16:03 | ||||
Взято с http://www.ibase.ru |
Автор: TObject 13.3.2008, 17:09 | ||||
|
Автор: 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, 19:38 | ||
Что-т я так и не понял по твоим словам получается, что необходимо переоткрывать НД и при CommitRetaining'e и при Commit'e |
Автор: TObject 14.3.2008, 09:44 | ||
При CommitRetaining Ваш НД остается открытым, но Вы не видите изменения сделанные другими пользователями. При Commit НД закроется сам (по крайней мере у меня так) и его прийдется открыть по новой. соответсвенно видим все изменения. Тоесть если нужно все время иметь свежие данные в НД, то прийдется переоткрывать в обеих случаях. |
Автор: Delphist 14.3.2008, 09:57 | ||||
И все же чем же плох CommitRetaining по отношению к Commit'y Нашел вот эту цитату:
Но из нее я так и ничего непонял и что значит CommitRetaining фактически препятствует сборке мусора, а простой коммит что не препятствует, и каком вообще мусоре идет речь? |
Автор: TObject 14.3.2008, 11:41 | ||
"Мусор" - это старые версии записей (результат многоверсионности), а вообще-то вот статья, читайте: http://www.ibase.ru/devinfo/oitoat.htm и вообще там есть много чего по СУБД IB/FB |
Автор: Deniz 14.3.2008, 11:54 | ||||
согласен. + http://www.ibase.ru/devinfo/ibtrans.htm
для начала:
|
Автор: Delphist 14.3.2008, 13:00 | ||
Какое-то противоречие И еще если у меня транзакция в открыта режиме ReadCommited, то тогда получается что Commited и CommitedRetaining одно, а если в режиме snapshot, то тогда Commited и CommitedRetaining не много разные вещи, правильно ли понял? |
Автор: TObject 14.3.2008, 13:22 | ||||
не видит изменения других транзакций, кроме своих, пока не переоткроется НД. |
Автор: Deniz 14.3.2008, 13:42 | ||
никакого противоречия нет. Мусор появляется не только от одной транзакции. Допустим стартанули 2 транзакции. 1. прочитала, потом добавила/обновила/удалила записи потом Commit. 2. прочитала, потом добавила/обновила/удалила записи потом CommitRetaining. Так вот мусор от первой транзакции соберется, а от 2 нет.
Так вот для клиента(при CommitRetaining) НД не закрывается и показывается весь текущий локальный кеш для записей. Новые данные поступят только после переоткрытия, сл-но если нужны правильные(новые) данные, то делать CommitRetaining + DataSet.Open нет никакого смысла, лучше CommiT + DataSet.Open. И это логично, т.е. CommitRetaining подтверждает другим транзакциям, что данные изменились. |
Автор: TObject 14.3.2008, 14:34 | ||||
To Deniz: В предидущем посте Вы действительно написали не совсем понятно, может думали иначе.
|
Автор: Deniz 14.3.2008, 15:51 |
а какие изменения можно увидеть на клиенте, не переоткрыв НД? Это же как отчет, напечатал смотришь, второй раз напечатал, смотришь новые данные. |
Автор: TObject 14.3.2008, 16:08 | ||
Я понимаю. Просто затупил на счет написаного в статье. Уже дошло. ![]() |
Автор: Delphist 14.3.2008, 20:16 | ||
А почему от второй не убирается мусор, ведь же CommitRetaining как бы содерджит в себе Commit, т.е. данные одназначно закомичены и откатить их нельзя, зачем тогда сервер сохраняет мусор (промежуточные изменения)? |
Автор: CompWorm 14.3.2008, 23:07 | ||
да, интересная тема.
это особенно интересно... и как бы его вычистить безболезненно)) |
Автор: TObject 15.3.2008, 01:46 | ||||
Как уже было выше сказано транзакция которая подтерждена по CommitRetaining остается активной, а соответсвенно является "заинетесованной" в тех записях с которыми она работает, поэтому другие транзакции не могут чистить "мусор" пока она не завершится по Commit.
Ну во-первых в сборке "мусора" участвует каждая транзакция, в том числе и read-only. Во-вторых backup БД делает уборку "мусора". В-третьих параметр sweep interval задает значение при достижении которого произойдет sweep. |
Автор: CompWorm 15.3.2008, 12:30 |
TObject, спасибо |
Автор: Deniz 17.3.2008, 06:19 |
делать COMMIT, а мусор сам соберется со временем, если только sweep interval > 0, если 0 мусор вообще собираться не будет |
Автор: Delphist 17.3.2008, 10:22 | ||
Что значит "заинетесованной", не совсем понятно? |