Вечная тема - транзакции InterBase.

← →
Vemer © (2004-01-07 21:34) [0]

Здравствуйте.
Пожалуйста помогите разобраться. Прочитал несколько статей и запутался.
Одни источники утверждают, что постоянный CommitRetaining не есть хорошо, в других написано, что если делать в начале .StartTransaction, то CommitRetaining работает как Commit но "без разрыва".
Что ближе к истине? В принципе я могу регулярно делать Commit, но это вроде незачем при втором варианте.

← →
jack128 © (2004-01-07 23:39) [1]

Раньше в реализации CommitRetaining был глюк, терялись ресурсы. Но в современных клонах(FB1.5) этот глюк, на сколько мне известно, исправлен.

← →
Vemer © (2004-01-08 00:18) [2]

А на Yaffil Personal 1.0 как с этим делом?

← →
div (2004-01-08 19:52) [3]

2 jack128: не совсем так - на самом деле весь прикол состоит в том что IB/FB при CommitRetaining накапливают "виртуальные" изменненные записи на сервере, которые существуют до тех пор пока не сделаешь обычный Commit. Что не означает потерю ресурсов, а их нерациональное использование на сервере. Поэтому использовать CommitRetaining нужно так сказать с умом, а то при очень интенсивной работе сервак начинает тупить (из личного опыта).

2 Vemer: что касается Yaffil Personal не могу ничего сказать. (

С уважением )

← →
jack128 © (2004-01-08 22:14) [4]

> div (08.01.04 19:52) [3]

Все могет быть -), я собственно никогда не испутывал нужды в этом методе, поэтому не вдовался в подробности.

А вообще зачем те CommitRetaining/RollbackRetaining ?
Используй обычные Commit/Rollback, а потом переоткрывай запросы.

ЗЫ такой прикол видел. Один чел так писал программы для работы в ib - он все транзакции CommitRetaining"ил каждые несколько секунд -)

← →
Vemer © (2004-01-08 22:24) [5]

Всем спасибо. Решил проблему компромиссом - мелкие изменения CommitRetaining, массовые - процедура с Commit + переоткрывание.

← →
Deniz © (2004-01-09 07:12) [6]

Попробуйте FIBPlus, хотя и в IBX можно реализовать подобное!
2 транзакции: 1 - чтение, 2 - запись. 2-ая транзакция ВСЕГДА завершается по COMMIT, причем она(транзакция) очень короткая, а после завершения Refresh в первой транзакции. И все.

← →
div (2004-01-09 10:07) [7]

Методы CommitRetaining / RollbackRetaining значительго облегчают жизнь нашему брату ))) да и к тому же если использовать Commit / Rollback то нагрузка на сеть нефиговая будет (если конечно у тебя не 100 запией ))). Подумай: неважно делаешь ты Commit или Rollback, следующий твой шаг - поднять данные с сервака... все... даже те которые ты не изменял...
А если совместить CommitRetaining с режимом кэшированных апдэйтов (извиняюсь за косноязычность))) нагрузка на сетку будет минимальной, а это сразу повышается производительность.
Хотя все конечно зависит от специфики посталенной задачи.

← →
Deniz © (2004-01-09 12:31) [8]

> div (09.01.04 10:07) [7]
Вообще-то на сервер нужно посылать только те данные, которые менялись, и " поднять данные с сервака..." звучит немного, хм, неправильно. Дело в том, что при изменении/добавлении записи некоторые поля могут изменится на сервере, но для нормального просмотра наобходимо только измененную/добавленную запись перечитать. И к тому же "тянуть" с сервера ВСЕ записи ... об этом уже говорилось не раз, ну не может(физически) пользователь работать с большим(зависит от конкретной задачи 10..100) кол-вом записей :)!

← →
Vemer © (2004-01-09 12:38) [9]

Прога локальная. Yaffil Personal. все данные вытягиваються маленькими порциями. И с электричеством не очень (UPS может будет). Поэтому важные изменения лучше Коммитить.

← →
Johnmen © (2004-01-09 14:34) [10]

Весьма полезно, особенно если с Чубайсом не на "ты", выставить базе ForcedWrites в Enable...

← →
jack128 © (2004-01-11 12:23) [11]

> Попробуйте FIBPlus, хотя и в IBX можно реализовать подобное!
> 2 транзакции: 1 - чтение, 2 - запись. 2-ая транзакция ВСЕГДА
> завершается по COMMIT, причем она(транзакция) очень короткая,
> а после завершения Refresh в первой транзакции. И все.

имхо в фибах не так сделано. Данные, после того как добавлены в базу, просто вставляются в локальный кеш датасета, никаких refresh"tей там нету..

← →
VID © (2004-01-11 17:59) [12]

Я например делаю так: Запросы на ПОЛУЧЕНИЕ данных, причём когда получаю множество строк(с последующим проходом по ним) я подтверждаю методом CommitRetaining, потому что эти запросы используют Transaction1, которая настроена как ЧИТАЮЩАЯ транзакция, и в таковой роли используется во всех tpfibdataset.

А запросы на вставку,удаление и изменение записей, я подтверждаю методом Commit, т.к. работа проиходит через Transaction2 которая настроена как ПИШУЩАЯ. И она же используется в качестве пишущей транзакции во всех датасетах.

Если же надо выполнить запрос на ПОЛУЧЕНИЕ данных, когда получена будет одна строка, то я использую Default-транзакцию базы данных - Transaction3 - которая является пищущей и читающей, и подтвержденеи этого запроса выполняю методом CommitRetaining.

← →
Johnmen © (2004-01-11 18:10) [13]

>VID © (11.01.04 17:59)

Чисто читающую тр-ию достаточно просто коммитить в конце работы программы, один раз.

>jack128 © (11.01.04 12:23)

Рефреш там есть. И делать его полезно, чтобы увидеть изменения от других клиентов...

← →
VID © (2004-01-11 18:18) [14]

To Johnmen: я знаю, но ведь эту же транзу в этот момент используют датасеты для отображения своих данных, и если я в каком нить читающем запросе, выполню Commint, то во всех датасетах данные пропадут - придётся их всех потом переоткрывать...

← →
Johnmen © (2004-01-11 18:20) [15]

>VID © (11.01.04 18:18)

Так я же и говорю, что коммит один раз в конце работы...:)

← →
VID © (2004-01-11 19:38) [16]

Johnmen... и то верно :)

← →
jack128 © (2004-01-11 19:52) [17]

> Рефреш там есть. И делать его полезно, чтобы увидеть изменения
> от других клиентов...
К сожелению исходников фибов нету, но имхо такой подход не есть good, если в dataset"e тяжелый запрос. Обновлять ВЕСЬ набор данных - слижком накладно. Refresh"ить нужно только текущую(добавленную) запись

← →
Johnmen © (2004-01-11 19:55) [18]

>jack128 © (11.01.04 19:52)

А я и говорил про одну, текущую, запись в НД.

Из этой фразы

> Рефреш там есть. И делать его полезно, чтобы увидеть изменения
> от других клиентов...

я сделал другой вывод :-). Что ж, тогда я все еще полон желания купить fib+

А блокировки CommitRetaining освобождает?
Ситауция:

1.
Транзакция A: select запись
Транзакция B: select запись
2.
Транзакция A: delete запись по where ключ = :параметр
CommitRetaining
3.
Транзакция B: delete запись по where ключ = :параметр
deadlock
Вопрос - с какого?

>Petr V. Abramov © (11.01.04 22:34)

Не совсем ясно про блокировки, т.к. IB версионник...

>Вопрос - с какого?

Так ведь первая тр-ия уже изменила запись. А во второй мы этого ещё не видим, т.к. селект "старый"...
А еще лучше почитать про это как обычно на ibase.ru :)

Спасибо за разные мнения.
Вопрос действительно вечным оказался. Вот как сделал в итоге в дополнение к (5). Две транзакции, одна читает неизменные списки, другая читает/пишет изменяемые. Делить на чисто чтение/запись неразумно по-моему (в моем случае) так как после внесения изменений все равно Open/close надо будет делать для некоторых динамических списков(хотя они read-only), вот они и дружно висят на 1-ой (второй).

> Johnmen © (11.01.04 23:06) [21]

Не-а :) Потому что по умолчанию isc_tpb_concurrency стоит, isc_tbp_read_commited + isc_tpb_rec_version - и все нормально

> т.к. IB версионник...
Ну и что, от этого блокировок нет? :) Мнение, конечно, официальное, но из серии "бескорыстного несения демократии иракскому народу" :) Ну или я чего-то важного не понимаю (:

По-любому, спасибо, что откликнулись :)

> Petr V. Abramov © (11.01.04 22:34) [20]
deadlock возникает в другом случае, в Вашем примере транзакция В получит отказ на обновление(raise), а вот пример deadlock"а:
тр1 и тр2 - транзакция 1 и 2 соот-но в режиме wait
тр1: update rec1
тр2: update rec2
тр1: update rec2
тр2: update rec1
Обе транзакции ждут завершения конкурирующих по Commit или Rollback. Вот здесь и будет deadlock.

> jack128 © (11.01.04 19:58) [19]
"Рефреш там есть. И делать его полезно, чтобы увидеть изменения от других клиентов..."
Из этой фразы, причем не совсем полно сформулированной, следует, что проходит Refresh, но не сказано, что Refresh"ится весь набор данных ... я уже писал это:
"... при изменении/добавлении записи некоторые поля могут изменится на сервере, но для нормального просмотра наобходимо только измененную/добавленную запись перечитать ...", именно так и поступает FIBPlus при Refresh"е. В фразе "на сервере" имелось ввиду, что таблица создана с использованием полей, изменяемых сервером. Т.е.
create table ...
upd_date date default NOW,
upd_user varchar(20) default CURRENT_USER
...
upd_date и upd_user просто пример.

>Petr V. Abramov © (12.01.04 03:15) [23]
> Не-а :) Потому что по умолчанию isc_tpb_concurrency стоит,
>isc_tbp_read_commited + isc_tpb_rec_version - и все нормально

А-а...Понятно. Это был тест на телепатические способности...:)

> Ну и что, от этого блокировок нет? :)

Нет. Просто можно их как бы "эмулировать".

>Мнение, конечно, официальное, но из серии "бескорыстного
>несения демократии иракскому народу" :) Ну или я чего-то
>важного не понимаю (:

:))) Я тоже...

Вечная тема - транзакции InterBase. Найти похожие ветки