|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Fedor 'Cruger' Tersin 2:5020/794.139 08 Jun 2001 01:20:57 To : sltoopls@kot.poltava.ua Subject : Hа: Informix ? --------------------------------------------------------------------------------
Sergey Practh навис на All
U> From: "Sergey Practh" <sltoopls@kot.poltava.ua>
>> Hе верю. И уже реализовал. Вполне нормальный. Разве что еще хотелось бы
U> Вот когда сделаешь, попробуешь, потом отправишь в эху, а мы здесь
U> потопчемся по твоему коду и в конце концов получится что-то путнее - вот
U> тогда скажешь "уже реализовал".
Выдирать ломает, могу рассказать схему.
Крутится сервис, в котором живут последние значения ключей. Триггер при вставке
ломится через внешнюю процедуру на сервис и берет очередное уникальное значение,
либо модифицирует его (если вставляемое значение ненулевое). При модификации в
случае изменения ключа обновляет его на сервисе. Вкратце все. Дальше детали.
Сервис, естественно, многопоточный с соответствующими блокировками, т.е.
уникальность каждого значения гарантируется.
Попадание в сервис актуальных значений происходит так: если на сервисе для
нужного объекта значения нет - процедура возвращает соответствующий статус,
триггер по нему делает select max и опять вызывает процедуру. Засада здесь такая
- если вдруг одновременно пойдет 2 вставки, причем хотя бы одна из них с
ненулевым ключем (или если кто то менять значение будет), может возникнуть
дэтлок. Ситуация крайне маловероятная (мало откуда могут взяться нормальные
значения ключа при вставке, а менять ПК, на который есть ссылки вроде бы и
незачем), а если применять грязное чтение, то и легко обходимая. Кроме того,
можно актуализировать значения непосредственно после старта сервиса.
Если идет bulk insert, ничего это не работает. Hу да это и нештатный режим
работы.
Если сервис сдох, длльку с процедурой снесли или еще что в этом духе - операция
откатывается.
Вот вроде и все. Работает это года 3, проблем пока не возникало. Возможно, есть
некоторые закладки на специфику задачи (ну, типа, что после старта сервера никто
не полезет толпою менять ПК), но имо легко учесть и более общие пожелания.
Fedor.
--- WP/95 Rel 1.78E (215.0) Reg.
* Origin: cruger@galaktika.ru && ICQ#5167246 (2:5020/794.139)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/469183d00793.html, оценка из 5, голосов 10
|