cherrex_Den morisКогда ASE убивает "жертву", то клиенту возвращается код -3. Правильно написанное клиентское приложение, должно по этому коду повторить транзакцию. ASE самостоятельно не будет сам проводить "жертву"

А это обусловленно какими-то постулатоми РСУБД или просто реализация такая? Почему несделать чтоб ASE сам бы заботился о "жертве"?

Это просто невозможно в принципе.
Сервер знает о том, какие операции произошли в транзакции до момента
дедлока, но не знает ничего о тех операциях, которые ещё должны были бы выполниться ПОСЛЕ дедлока,
просто потому, что они ещё не успели выполниться.



Кроме того, последующие операции вообще могут быть произвольными, например, если генерируются
клиентом в зависимости от условий, или зависят от данных.

Ну и наверное не надо говорить о том, что транзакция может как утверждаться (commit) , так и откатываться,
также в зависимости от данных, иначе вообще зачем транзакции нужны ...

Zhora wrote:

> Я думаю что так и должно было бы быть если бы все было "по уму", т.е.
> СУБД должна была бы сама заботиться о повторе victim transaction, а не
> возлагать еще и это на плечи бедного application,

Ну, Zhora, от вас я такого не ожидал, вы же вроде бы грамотный
специалист ... А если подумать немного ? В общем, читайте,
что я

тем более что
> код ошибки (@@error) = 1205, который возвращается servero-m невозможно
> проверить ни в sp,

Да, вы правы, невозможно, потому что выполнение SP прерывается.
Выполнение потока управления многооператорного батча, посланного
на сервер, тоже. Поэтому средствами TSQL это вообще никак не
обнаружить, просто потому, что TSQL в этом случае УЖЕ НЕ БУДЕТ
ВЫПОЛНЯТЬСЯ.

ни в ODBC (по крайней мере в старых версиях), только
> через Open Client (а если у вас только cвязка VB/CRW/ODBC -> sp, что
> делать ?).

Ну, возможно это драйвер кривоват был для ASE. Для MS SQLServer 6.0
я помню точно эта ошибка обнаруживалась, и я её обрабатывал
именно на ODBC.

Кстати, как ни странно, я с ASE через ODBC практически вообще
никогда не работал - только OpenClient

> Насчет return status (code) = -3 не пробовал проверить, может и можно,
> хотя сомеваюсь, т.к. "проверялка" сама должна быть в коде скажем этой же
> sp a она сразу отрубается как процесс сервером.

Никакого кода не будет, возможно, при вызове процедуры с клиента
будет сэмулирован какой-то плохой код, как это делается в случае
с вызовом несуществующей процедуры.
Posted via ActualForum NNTP Server 1.4

cherrex_Den wrote:
> Так не просто транзакция откатывается, а весь процесс киляется? Что-то я
> запутался!!!

На сколько я помню, соединение не разрывается.
Процесс прекращается, т.е. останавливается выполнение
всех посланных комманд (и текущей выполняемой также).
Транзакция откатывается. Соединение переводится в состояние,
когда оно может принимать последующие запросы.
Posted via ActualForum NNTP Server 1.4

cherrex_Den wrote:

> А можно по подробней! Я выполняю какую-то транзакцию, в середине попадаю
> в дэдлок, транзакция откатываеться. Что мешает еше раз выполнить этот
> скрипт который был перед дэдлоком?

Ничего, это выполнить можно.
Вопрос в другом - что делать дальше, чтобы завершить транзакцию.

Догатка у меня только одна, что некое
> "третье лицо" во время пока сервер разбирался с дедлоком, произвел
> изменение данных и согласованность уже нарушилась.

И это, кстати, тоже.
Posted via ActualForum NNTP Server 1.4

Zhora wrote:

> Я тоже так думаю, по крайней мере я использую некий стандарт где все
> транзакции начинаются и
> заканчиваются (begin tran,commit tran, rollback tran, savepoint) внутри
> sps, a не где-то в "стороне" (в application),
> так что server "ситаксически" осведомлен о них "эаранее",
> а не только в момент выполнения и мог бы "проследить" за ними.

Это - только один из возможных подходов. А сервер расчитан на ВСЕ.
Но даже в случае, если мы имеем хранимую процедуру со всем кодом,
и дедлок произошёл в процессе её выполнения, невозможно автоматически
перевыполнить её, поскольку далее (после дэдлока) в процедуре может быть
какой-то код, который осуществляет ветвление на основе прочитанных
данных и в таком случае сервер просто не будет знать, по какой ветке
идти. Для этого надо было бы прочитать данные еще раз, т.е. "накатывать"
процедуру не с использованием лога записанных операторов и изменённых
ими данных, а просто перезапуская процедуру. А это уже будет в другой
транзакции. Этого сервер не имеет право делать.

> Вот поискал и отрыл , мне кажется одно подтверждение: "lexical
> transactions" с автоматическим рестартом сервером
> после deadlock situation в ObjectStore (Progress.com/IBM ?),
> хотя может и притянуто за уши (мной):

Да, наверное. Дело в том, что под словом "транзакция" скрывается
реально очень много терминов, совершенно разных. Т.е. транзакции
бывают разные. В той модели транзакций видимо специально оговорено
такое поведение. В ACID -транзакциях из ANSI SQL такого нет.
Posted via ActualForum NNTP Server 1.4

Zhora wrote:

> после deadlock situation в ObjectStore (Progress.com/IBM ?),
> хотя может и притянуто за уши (мной):
> http://progress.atgnow.com

почему-то не удалось мне прочитать страницу эту. Там
в центре - пустое поле и всё. Сама страница загружается.
Там на флешах что ли всё ?
Posted via ActualForum NNTP Server 1.4

Zhora wrote:

> Не знаю, но я теперь тоже не могу прочитать, хотя вчера мог. Что
> касается транзакций - это самые обычные "ACID транзакции". Ну я думаю
> серверу даже в случае "application transaction" (moe), для повтора после
> deadlock достаточно опять дойти до точки deadlock-a используя как-то
> свой trlog (a может и vce rollback-ать to необязательно было бы ?),
> короче используя свои внутренние механизмы, а затем опять "отдаться"
> приложению, тогда ему (серверу) совсем не нужна будет информация о том
> что там будет "дальше", уже опять будет продолжать "рулить" application,

Вот когда придумаешь API для этого действа, тогда и поговорим.
О сложности такого мероприятия я уже и не говорю, начать хотя бы
с того, что клиент должен стать и сервером тоже, чтобы АСИНХРОННО
принимать запросы на "продолжение выполнения чего-то там".

> сделать это прозрачным для application воoбще (или пoлупрозрачным как в
> этом ObjectStore где можно задать лимит повторов после deadlock-a) безо
> всяких error типа 1205.


>
> Sybase "любит" деадлочить пусть сам и разбирается с этим до конца
> ("саночки возит"), а не "проливает кровь безвинных жертв/victims", да
> еще под лозунгом "спасение утопающих-дело рук самих утопающих".

Sybase тут далеко не одинок, все СУБД делают аналогичным образом.
Не у всех есть deadlock tune и вообще обнаружение дедлоков - большинство
СУБД попроще ограничиваются просто тайм-аутами на ожидание, т.е. что
это именно deadlock вообще не определяется. Не получил блокировку вовремя-
всё, иди на фиг со своей транзакцией.

> Вообще по части перекладывания ответственности на developer/DBA Sybase
> ASE явно "впереди планеты всей", чего стоит одно dump trlog, без
> которого СУБД просто остановится, а за который почему-то отвечает DBA со
> своими доморощенными скриптами. Hy сделайте наконец-то что-то типа
> archivelog mode как в Oracle.

Так, разагитировался
В общем, это не соответствует действительности. Впереди планеты всей,
как известно, по этому показателю именно оракл. (хотя я не в общем
лишь передаю общеозвученное мнение, ну, давайте будем считать, что
они одинаковы, но вот что ASE сильно как-то хуже, я не думаю).
А на счёт логов, так уж наверное ты знаешь , как законфигурить
ASE, чтобы она автоматом лог в базе обрезала. И знаешь, зачем сделана
возможность, чтобы лог НЕ обрезался автоматом. Так зачем всё это ?
(вопрос риторический).
Posted via ActualForum NNTP Server 1.4

cherrex_Den wrote:

> А есть способ искуственно создать deadlock, чтоб отладить клиентское
> приложение(код-3)?

Конечно.
Имитирующий скрипт пишется легко.
Только надо это делать в двух коннекциях.
Одна из них должна быть коннекцией тестируемого приложения.
Posted via ActualForum NNTP Server 1.4

cherrex_Den wrote:

> > А есть способ искуственно создать deadlock, чтоб отладить клиентское
> > приложение(код-3)?

Вот, публицирую с любезного разрешения автора.
Запустив данную процедуру в двух соединениях из двух потоков (или приложений)
более-менее в одно время гарантированно получишь deadlock.


Posted via ActualForum NNTP Server 1.4