|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 06 Jun 2001 12:19:46
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Fedor 'Cruger' Tersin wrote in message
<2175732613@p139.f794.n5020.z2.ftn>...
> U> всеми возможностями сервера тебе позволено явныи образом управлять.
>Допустим, но тогда нужно уметь их обрабатывать. Это можно делать на одном
из 3х
>уровнях: автоматом на уровне сервера,
Сие не возможно. Сервер не знает, нужно ли повторять запрос при DEADLOCK.
Кроме того, конкретно в MS при этом соединение разрывается AFAIR, т.е.
запрос повторять просто HЕГДЕ.
>на уровне инструментария (прослойки междуприкладухой и сервером),
Это можно, но прослойка не всегда может знать о том, надо ли повторять
запрос.
Если интересно, могу привести конкретный пример из моей личной практики.
>либо на высокоуровневом прикладном коде. Первые 2
Вот это скорее всего. И идеальнее :-))
>уровня почти идентичны - ведь ни тот, ни другой ничего о специфике запроса
не
>знают (т.е. им недоступна логика, приведшая к этому запросу). В то же
время,
Именно по этому первые два уровня не годятся.
>Тенцер прав - существует довольно обширный класс запросов, которые можно
смело
>перевыполнять до победного конца. В свете вышесказанного, разумно иметь
такой
>механизм на уровне сервера, естественно, опциональный. Учитывая
относительную
Типа опциональный на уровне запроса ? Или сессии ? Или чего ?
ЧТО ты собираешся повторять при DEADLOCK-е ? Всю историю запросов
от начала транзакции ?
>важность проблемы (раз уж трабл может случиться в любое время), странно,
что ни
>в одном сервере это не реализовано. Более того, я видел советы, по
Потому что это HЕВОЗМОЖHО !! Ты об этом не подумал ?
>проектированию БД с целью избежания дэтлоков, но не встречал рекомендаций и
>заготовок для работы в условиях спонтанных дэтлоков. В общем, странно все
это.
Как раз в MS -овской доке есть четкое описание что надо делать - а именно,
клиент должен повторить все действия с момента старта последней транзакции.
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
