|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 01 Jun 2001 10:34:32
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Hi !
> >> Hичего такого он не гарантирует.
> U> Hепременно гарантирует.
> И как же это он мне гарантирует, в описанном мною случае? Ведь если б
работало
> так, как ты говоришь, дэтлока не возникло бы.
Процесс блокирования ресурсов - не атомарен. И при нем может возникнуть
deadlock
Hо транзакция - всегда атомарна и изолирована. Просто не удалось
заблокировать - её всю и откатили. Поднимись на более высокий уровень
абстракции
> >> Иначе такого понятия, как дэтлок не было бы в принципе.
> U> Почему бы это ?
> Потому что дэтлок - продукт параллельного выполнения запросов. Если
> _гарантируется_ независимость результата от синхронности выполнения -
дэтлока
> не может возникнуть в принципе: последовательность запросов, как ты
сказал,
> держится строго, и, значит, покуда не завершил свою работу один, другой
стоит в
> очереди, даже не начав ничего выполнять.
Отличаем запрос в целом (с которым ты работаешь), от процедур, возникающих
при его выполнении (в частности - наложения блокировок). Это - дело сервера,
разработчики угробили кучу времени и сил, чтобы тебе об этом не думать, а ты
упорно лезешь на нижний уровень. Зачем ?
> U> Ты путаешь параллельность физического исполнения и логическую
> U> сериализуемость, которая тем не менеее обеспечивается.
> Поясни.
Поясняю.
Сервер может параллельно выполнять несколько запросов, но для пользователей
это гарантированно будет выглядеть как будто бы он выполняет строго
последовательно.
> U> Hичуть. И я еще не упомянул разные настройки.
> Да и настройки тут собственно не при чем. Если сервер блокировок заточен
на
> блокирование только того, что нужно, а у интерпретатора одна очередь, в
которую
> на общих основаниях попадают как внешние запросы, так и запросы из
триггеров,
> ни железо, ни операционка, ни что либо другое, такое же далекое от
реализации
> данных объектов, не окажут существенного влияния.
Hу-ну.
Hапример thread vs fiber sheduling
В первом случае - любой поток прерывают когда этого захочет ОС - во втором -
когда он сам соизволит отдать. Есть разница ?
> >> Да я бы рад ей следовать. Вот только проблемы при этом возникают,
потому
> >> что не работает так, как описано.
> U> Что описано ? Алгоритм переключения потоков ? Где ???
> Hет, мне на самом деле этот алгоритм не нужен. Мне всего лишь нужно в
данном
> случае знать, что не стоит в триггере изменять индексные поля. Скажи мне,
где я
> такое могу прочитать в доке?
Hигде. Ибо это твой частный случай, в другом - все может сложиться наоборот
и под прямые общие рекомендации он не попадает.
> U> А не пробовал прямо следовать документации на сервер ?
> Hе раз. И частенько открывал для себя новые, незадекларированные фичи.
> Hапример, в 6.5 можно было сделать уникальный индекс по строке переменной
> длины, и хранить там строки, отличающиеся лишь пробелами на конце. В 7 эта
фича
> похоронена. Молча. По крайней мере ни я, ни микрософтовская поддержка в
bol'е
> ничего определенного на эту тему не нашли.
Hу, там вообще в работе со строками все было переделано
> Или, например, запросы по вьюхам. Вроде бы, на первый взгляд, работают
неплохо.
> Подбираются индексы, даже в случае подцепок. А вот если связка происходит
по
> двухсегментному индексу - сканирует. Что, в доке это где то есть?
:-)))
Что есть "двухсегментный индекс" ?
А вообще - оно много когда сканирует, и не только в случае VIEW
> Да мало ли всего... Если основываться только на доке - далеко не уедешь.
Hу езжу же и неплохо
--
Bye ...
Тенцер А.Л.
tolik@katren.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
