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

Вниз

вариации с транзакциями   Найти похожие ветки 

 
July   (2006-04-13 12:31) [0]

Проблема такая - есть транзакция 1-го типа (t1), запускается редко и не должна допускать параллельного выполнения с транзакциями 2-го типа (t2), которые запускаются регулярно и часто.
Есть вариант устанавливать флаг перед запуском t1 (хранить его, вероятно, в виде значения поля в какой-нибудь специально для этого заведенной таблице), делать коммит (чтобы транзакции t2 при попытке запуска могли видеть это значение и завершаться с ошибкой),
потом запускать t1, после нее независимо, успех или откат - сбрасывать флаг и снова делать, естественно коммит. Теперь t2 по идее должны нормально начать работать.
Так вот, все бы хорошо, но как быть, если будет какой-нибудь сбой после установки этого флага - t1-то откатится, а флаг-то останется установленным. И не откатить его, получается, никак :( Как быть? Что посоветуете?

Отсюда вытекает еще вопрос, он возникает у меня часто не только в связи с этой проблемой - нет ли в IB(7.5) чего-то вроде глобальных переменных, изменение значений которых становилось бы видно всем транзакциям сразу (без коммита) и в тоже время при аварийном завершении транзации, изменившей это значение, возвращалось бы старое. Т.е., видите ли, хочется частичной поддержки чтения "грязных" данных, знаю, что IB в принципе это не поддреживает, но может можно как-то изголиться ;)
Попробовала манипулировать значением генератора - его изменения сразу видны, но не откатываются..

Посоветуйте, что почитать по теме?


 
Sergey13 ©   (2006-04-13 12:36) [1]

А каково жизненное наполнение этого желания? Другими словами - чего делаем, чего хочется?


 
Johnmen ©   (2006-04-13 12:38) [2]

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


 
Курдль ©   (2006-04-13 12:41) [3]

Извините, за оффтоп, но я всегда преклонялся перед программистами IB за их возню с транзакциями.
Более того, посыпая голову пеплом, могу признаться, что до сих пор не понял, что это за зверь "Читающая транзакция"?..


 
Johnmen ©   (2006-04-13 12:42) [4]

Я тоже прошу прощения за оффтоп, но "Читающая транзакция" это та, в рамках которой происходит только чтение.


 
Курдль ©   (2006-04-13 12:58) [5]


> Johnmen ©   (13.04.06 12:42) [4]

А зачем она нужна? Вроде все остальные СУБД обходятся без таковой?..

:(


 
July   (2006-04-13 13:03) [6]


> А каково жизненное наполнение этого желания? Другими словами
> - чего делаем, чего хочется?

Ну, про предметную область рассказывать слишком муторно.
В общем надо, чтобы когда запускается одна процедура (в t1) до ее завершения не могли запуститься процедуры другого типа (t2).
Блокировка полная (по table stability с protected write) одной проблемной таблицы (для которой нелья допусить даже чтение процедурой из t2) не подходит, потому что будет блокировать и тормозить другую работу.


 
Johnmen ©   (2006-04-13 13:11) [7]


> Курдль ©   (13.04.06 12:58) [5]
> А зачем она нужна? Вроде все остальные СУБД обходятся без
> таковой?..


Она просто есть. По определению. Все остальные СУБД без неё не обходятся, просто её не "видно".


 
Sergey13 ©   (2006-04-13 13:18) [8]

2[6] July   (13.04.06 13:03)
Может как то ночью запускать эту процедуру или предварительно всех выгонять из базы?


 
July   (2006-04-13 13:42) [9]


> Может как то ночью запускать эту процедуру или предварительно
> всех выгонять из базы?


Да если бы все было так просто :)
Не-е, надо в рабочее время.
И чтобы не пользователи друг друга уведомляли - "та-ак, щас буду делать ЭТО и чтобы никто вон-то не делал!" :)) а чтобы все цивилизовано было, да и если пользователи друг друга не послушаются или не предупредят, бывают всякие глюки, которые руками приходится лечить..
Только не спрашивайте о причинах, из которых это все тянется, изменить это не в моей власти ;)


 
Sergey13 ©   (2006-04-13 14:06) [10]

2[6] July   (13.04.06 13:03)
> потому что будет блокировать и тормозить другую работу.
А фактический запрет работать всем остальным не будет тормозить?
Можно попробовать завести отдельную транзакцию 3-го типа 8-), задача которой будет только в снятии/постановке флага. Т.е. изолировать установку флага от первой страшной транзакции.

2[9] July   (13.04.06 13:42)
> Только не спрашивайте о причинах, из которых это все тянется, изменить это не в моей власти ;)
Ладно, не буду. 8-)
Но замечу, что лечить причину намного эффективнее, чем симптомы.


 
July   (2006-04-13 17:32) [11]


> Можно попробовать завести отдельную транзакцию 3-го типа
> 8-), задача которой будет только в снятии/постановке флага.
>  Т.е. изолировать установку флага от первой страшной транзакции.
>


Так ее все равно придется завершить, чтобы установка флага стала видна всем остальным.
Потом после завершения t1 - опять запускать для сброса флага.
Мало ли чего перед этим произойдет.. connection lost и он останется висеть..
В общем, придется видимо для такого крайнего (я надеюсь :)) случая добавлять в приложение что-то вроде функции "устранение неполадок",
чтобы всегда можно было насильно этот флаг сбросить..


> Но замечу, что лечить причину намного эффективнее, чем симптомы


Это да, бесспорно.
Но в моем случае в настоящий момент низзя :)


 
atruhin ©   (2006-04-13 18:06) [12]

Вообще глобальные переменные для (общие, сессии, транзакции) есть в Firebird 2.0. А в IB все-таки приведи простой теоретический пример для чего это нужно, может кто чего подскажет.



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

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

Наверх




Память: 0.48 MB
Время: 0.036 c
3-1144917116
July
2006-04-13 12:31
2006.06.04
вариации с транзакциями


2-1147676291
Мурзилка
2006-05-15 10:58
2006.06.04
TTreeView


15-1147418488
Думкин
2006-05-12 11:21
2006.06.04
А вы говорите...


3-1144513827
VadimSpb
2006-04-08 20:30
2006.06.04
Экспорт в Excel


15-1146854038
Постоялец
2006-05-05 22:33
2006.06.04
Освоение 1C





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
Английский Французский Немецкий Итальянский Португальский Русский Испанский