Как лучше заканчивать транзакцию на чтение?

← →
kaif © (2003-09-10 22:19) [0]

Приложение часто делает мелкие запросы на чтение в отдельных транзакциях (только SELECT). Можно такие транзакции заканчивать с помощью commit, а можно rollback. Что экономнее для ресурсов сервера? Или все равно?
Буду признателен за любые соображения.

← →
Sergey_Masloff (2003-09-10 23:08) [1]

Если только SELECT то ИМХО абсолютно параллельно что коммит что роллбэк. При selecte версии записей не создаются так что накладные расходы на завершение минимальны.

← →
Evgeny V © (2003-09-11 06:22) [2]

При select лучше commit, по накладным расходам, ссылка - книга "Мир InterBase" авторы Ковязин и Востриков

← →
Johnmen © (2003-09-11 09:14) [3]

Commit оптимальнее, если тр-ия только читающая.

← →
stone © (2003-09-11 09:28) [4]

А зачем вообще в этом случае стартовать явную транзакцию? Разве неявные транзакции уже отменили?

← →
Alexandr © (2003-09-11 09:33) [5]

в firebird есть реадонли транзакция. Самое то для селектов.
А завершать лучше по коммит.

← →
jack128 © (2003-09-11 11:29) [6]

при определенных параметрах трансакции (read only и еще что, точно не помню) не создается версий записи, а транзакция стартует УЖЕ в commit - состоянии. firebird и yaffil если в трансакции были только select запросы, то rollback автоматом заменяется на commit).. Все описано на ibase.ru

← →
kaif © (2003-09-11 11:50) [7]

Всем спасибо!
Я инстинктивно использовал везде commit.

2 Alexandr © (11.09.03 09:33) [5]
Интересно про readonly транзакции... Хотя я стараюсь не закладываться на определенный тип сервера. У меня программа на рынок.

2 stone © (11.09.03 09:28) [4]
Явные старты мне пришлось применять, так как если транзакция стартовала неявно и кроме select-а что-то делалось (тем не менее), то с некоторой вероятностью при многопользовательской работе в сети у меня сервер зацикливался (Yaffil-821). Поэтому я все старты переделал на явные. К сожалению, причина зацикливания сервера в этом. Хотя это эмпирический, но уже факт, подтвержденный многократно...

← →
Romkin © (2003-09-11 11:56) [8]

2kaif read read_committed rec_version nowait - типовая самая легкая транзакция (практически ее нет), просто читаешь данные

← →
Alexandr © (2003-09-11 12:38) [9]

дык и так readonly транзакции есть в FB, Yaffil
Interbase 6.5 и выше не смотрел. не знаю. Но что-то мне подсказывает, что скорее есть, чем нет.

← →
kaif © (2003-09-11 16:00) [10]

спасибо
Romkin © (11.09.03 11:56) [8] и
Alexandr © (11.09.03 12:38) [9]

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

Теперь такой вопрос. У меня в системе много мелких транзакций на чтение, создаваемых runtime. Однако есть и одна глобальная, с которой (исторически так получилось) много мелких таких запросов работает.
Что правильнее?
Иметь одну долгую глобальную транзакцию readonly read_committed для таких дел или лучше вообще не иметь долгих транзакций, даже readonly?

← →
Zacho © (2003-09-11 16:07) [11]

> kaif © (11.09.03 16:00) [10]

Имхо, долгая read_committed read - вполне нормально, и никаких доп. нагрузок, неудобств, удержания версий и т.п. не приносит.

← →
kaif © (2003-09-11 16:15) [12]

Что же, вырисовывется даже некоторая неплохая идеология...
Одна длинная readonly для всякой всячины и отдельные недолгие read_committed nowait транзакции для апдейтов или селектов, могущих закончиться апдейтами.

← →
Johnmen © (2003-09-11 16:19) [13]

>kaif © (11.09.03 16:15)

Лично я именно так и делаю :)

← →
Sergey_Masloff (2003-09-11 23:30) [14]

Johnmen © (11.09.03 16:19) [13]
>Лично я именно так и делаю :)
Думаешь ты один? ;-)

> и отдельные недолгие read_committed nowait транзакции для
> апдейтов или селектов, могущих закончиться апдейтами.

а вот это лучше в snapshot делать

snapshot вроде (где-то читал) много ресурсов жрет, так что я его редко применяю, разве что для строгих отчетов, требующих "снимка базы".

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

2 Alexandr © (12.09.03 14:42) [18]
Я как правило работаю в оптимистической модели (задачи учета).
У меня два юзера как правило одни и те же данные не редактируют. Хотя для пессимистической модели ты прав.

ну дык. тогда и ресурсов с чего бы ему много жрать...

Как лучше заканчивать транзакцию на чтение? Найти похожие ветки