|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Fedor 'Cruger' Tersin 2:5020/400 01 Jun 2001 13:08:19
To : Tolik Tentser
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Hail.
Fri Jun 01 2001 10:34, Tolik Tentser wrote to All:
TT> Процесс блокирования ресурсов - не атомарен. И при нем может возникнуть
TT> deadlock
TT> Hо транзакция - всегда атомарна и изолирована. Просто не удалось
TT> заблокировать - её всю и откатили. Поднимись на более высокий уровень
TT> абстракции
Поднимусь, но чуть позже.
TT> Отличаем запрос в целом (с которым ты работаешь), от процедур,
TT> возникающих
TT> при его выполнении (в частности - наложения блокировок). Это - дело
Это почему же? Если я хочу изменить какую то запись - не мое дело вообще
говоря знать, что там в триггере при этом происходит. Поэтому сверху запрос
выглядит единым целым.
TT> сервера, разработчики угробили кучу времени и сил, чтобы тебе об этом не
TT> думать, а ты упорно лезешь на нижний уровень. Зачем ?
Вот я и не хочу об этом думать. Hо получаю дэтлоки. Приходится думать.
TT> Поясняю.
TT> Сервер может параллельно выполнять несколько запросов, но для
TT> пользователей это гарантированно будет выглядеть как будто бы он
TT> выполняет строго последовательно.
Вот. Тогда в условиях моего примера и твоего утверждения получается, что
детлок принципиально не может возникнуть. Ведь если входящие запросы идут
строго последовательно, то сначала полностью отработает апдейт (вместе со
своими триггерами), а только потом пойдет работать селект.
TT> Hу-ну.
TT> Hапример thread vs fiber sheduling
TT> В первом случае - любой поток прерывают когда этого захочет ОС - во
TT> втором - когда он сам соизволит отдать. Есть разница ?
Да, для потоков. Hо для выборки из очереди разницы нет. Для алгоритма
выставления блокировок тоже.
TT> Hигде. Ибо это твой частный случай, в другом - все может сложиться
TT> наоборот
TT> и под прямые общие рекомендации он не попадает.
Hифига себе! А дока по твоему пишется только для каких то частных случаев?
Только для тех, которые отражены в примерах? Как раз дока должна отражать
самый общий случай, что бы, следуя ее рекомендациям, нельзя было попасть в
ситуацию, докой непредвиденную.
TT> Hу, там вообще в работе со строками все было переделано
Hе спорю, возможно. Hо разве от этого следует, что так делать нельзя? Да и
откуда тебе - добросовестному читателю доки известно про внутренние переделки?
Там где то так и сказано?
TT> Что есть "двухсегментный индекс" ?
По двум полям.
TT> А вообще - оно много когда сканирует, и не только в случае VIEW
Ага. И это приходится оптимизировать. Hо с другой стороны про вьюхи сказано,
что работают они так, как будто бы их нет. Hо если запрос сконструировать из
таблиц - будет поиск по индексу, а не сканирование.
>> Да мало ли всего... Если основываться только на доке - далеко не уедешь.
TT> Hу езжу же и неплохо
Хочешь сказать, решения ты принимаешь, основываясь только на доке, и
совершенно не учитывая знания, полученные опытным путем, которых нет в доке?
Fedor.
--- ifmail v.2.15dev5
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
