Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.06.04;
Скачать: CL | DM;

Вниз

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

 
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;
Скачать: CL | DM;

Наверх




Память: 0.5 MB
Время: 0.044 c
2-1148016114
Близнец
2006-05-19 09:21
2006.06.04
ShellExecuteEx и WaitForSingleObject


15-1147102927
Иксик
2006-05-08 19:42
2006.06.04
День Победы!


2-1148034482
VEZ
2006-05-19 14:28
2006.06.04
raise in Constructor


2-1147699621
Ironman83
2006-05-15 17:27
2006.06.04
Выборки через TIBDataset


2-1148022112
Alien1769
2006-05-19 11:01
2006.06.04
Нормализация базы