Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.10.02;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]
>Лично я именно так и делаю :)
Думаешь ты один? ;-)


 
Alexandr   (2003-09-12 07:22) [15]


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


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


 
Deniz   (2003-09-12 08:46) [16]

> Alexandr © (12.09.03 07:22) [15]
>а вот это лучше в snapshot делать

А вот это(snapshot) для отчетов.


 
kaif   (2003-09-12 14:35) [17]

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


 
Alexandr   (2003-09-12 14:42) [18]

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


 
kaif   (2003-09-12 14:45) [19]

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


 
Alexandr   (2003-09-12 14:53) [20]

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



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.10.02;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.48 MB
Время: 0.009 c
14-4043
саша2
2003-09-16 10:11
2003.10.02
где форум?


14-4119
Vovchik_A
2003-09-12 17:26
2003.10.02
Люди в черном 3...


7-4149
Павел
2003-07-20 20:24
2003.10.02
Имя файла


6-4035
volser
2003-08-05 01:09
2003.10.02
Как отследить подключение и разрыв связи к интернету


14-4065
Igorek
2003-09-12 11:07
2003.10.02
Что такое ЛЕНЬ?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский