| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
2000 Ошибки с транзакцией [MSSQL]
KAA © (2002-08-16 11:51:00)При написании программы периодически допускаешь ошибки, в частности можно где-то не закрыть транзакцию. В результате клиентские приложения просто подвисают, пока не закроют подвисшего клиента. Но это блокирует работу и остальных клинетов, работающих с этой таблицей. А этих клиентов может быть штук 50, и сидят они по всему зданию.
Есть процедуры sp_lock и sp_who, с помошью которых по идее можно понять где и с чем произошла ошибка. Но как разобрать выдаваемую этими процедурами информацию я не знаю. Подскажите, что означают эти результаты.
KAA (2002-08-21 17:31:00) [1]Самое что смешное, я могу привести веские доводы необходимости разбивания яйца как с одной, так и с другой стороны. :)
vuk (2002-08-21 17:14:00) [2]А я давно написал, что все это вроде войны остроконечников и тупоконечников - с какого конца яйцо разбивать. :o)
Desdechado (2002-08-21 16:57:00) [3]Занимательная беседа ...
Плотник со столяром анализируют качество дров :)
А дрова-то не березовые, а из прессованного угля.
KAA (2002-08-21 16:29:00) [4]Вообщем это можно сравнить с залезанием на скалу со страховкой и без. В обоих случаях неумелые действия могут првести к падению, но со страховкой всеж надежней.
KAA (2002-08-21 16:21:00) [5]Но в моем случае меньше вероятности того, что в клиенте будет такая ошибка.
vuk (2002-08-21 16:07:00) [6]О! Так вот, ни в том ни в другом случае процедуры в базе друг другу мешать не будут. :o) С другой стороны неправильно написанный клиент может свести на нет все усилия.
KAA (2002-08-21 15:51:00) [7]Тогда наверно мы друг друга не поняли.
Если одна хранимая процедура в базе может мешать другим процедурам, это ошибка базы. База будет рабочей когда в ней не будет ошибок.
А вот клиент это уже вторая задача. Если ошибка в клиенте, это не должно затрагивать базу. База должна остаться рабочей.
vuk (2002-08-21 15:42:00) [8]>Но кроме транзакции может потребоваться написать еще целый ряд
>команд.
Елы-палы...
Я у Вас пытаюсь выяснить, что будет, если Вашу процедуру вызывать внутри транзакции... Вы уверены, что это не будет мешать другим процедурам? Меня сейчас в других конструкциях глюки не интересуют.
KAA (2002-08-21 15:33:00) [9]>Транзакция - она и в Африке транзакция, и к языку программирования отношения не имеет.
Но кроме транзакции может потребоваться написать еще целый ряд команд. Вот там глюк и затаится.
Да и вообще, можно просто так взять и написать другую конструкцию. Неважно по какой причины, если такая ситуация возможна, значит рано или поздно она произойдет.
>Так не получится же на все 100% это обеспечить. На все случаи жизни застраховаться не удастся.
Клиент может запускать хранимые процедуры. Если ни одна из этих процедур не будет мешать другим, то и клиент уже ничего не сделает с базой.
vuk (2002-08-21 15:25:00) [10]>А язык может вносить свои нюансы, из-за которых не получится
>такой ход действий.
Транзакция - она и в Африке транзакция, и к языку программирования отношения не имеет.
>Так вот она не должна мешать остальным.
Так не получится же на все 100% это обеспечить. На все случаи жизни застраховаться не удастся.
KAA (2002-08-21 15:09:00) [11]>Вы так и не поняли о чем я. Я имею в виду ход действий на клиенте. При чем здесь язык-то?
А язык может вносить свои нюансы, из-за которых не получится такой ход действий.
Моя логика такая, если в клиенте ошибка, она должна максимум проявляться в работе с этим клиентом. Из-за нее не должна подвисать база. И нельзя закладываться на то, что клиент будет написан так и никак иначе.
>>А мне не нужны виноватые в том, что база подвисла. Мне нужно чтоб она не подвисла.
>Гм... При другой логике работы клиента - запросто. То есть Вы тоже завязываетесь на реализацию клиента.
Представьте что с базой работают два разных клиента, написанных двемя разными людьми. Мало того, у каждого клиента было много версий и на разных компьютерах стоят разные версии. Предположим в одной из версий одного из клиентов ошибка, которая еще и не всегда проявляется. Так вот она не должна мешать остальным.
vuk (2002-08-21 14:43:00) [12]>А предположим что нету. Клиент пишется с нуля. Например на
>другом языке.
Ну елы-палы... :-(
Вы так и не поняли о чем я. Я имею в виду ход действий на клиенте. При чем здесь язык-то?
>А мне не нужны виноватые в том, что база подвисла. Мне нужно
>чтоб она не подвисла.
Гм... При другой логике работы клиента - запросто. То есть Вы тоже завязываетесь на реализацию клиента.
KAA (2002-08-21 14:31:00) [13]>Так Вашим правилам тоже нужно следовать.
Но им должны следовать писатели сервера.
>Определенные требования к клиенту выдвигаются в обоих случаях, просто они разные.
Да, и в моем случае клиенту выдвигается меньше требований, к чему мы у себя стремимся.
>Предположим, что есть такой код(схематично):
А предположим что нету. Клиент пишется с нуля. Например на другом языке.
>Ответственность за соблюдение правил лежит непосредственно на
>разработчике. Он либо их соблюдает и тогда софт вписывается в
>существующую инфраструктуру (как он их будет соблюдать -
>проблема разработчика), либо - нет. Если нет - по рогам ему!
А мне не нужны виноватые в том, что база подвисла. Мне нужно чтоб она не подвисла.
У нас всеж разные подходы.
В вашем случае, база и клиент - одна задача. А у меня это две задачи, просто они нужны обе. Но у меня в базе есть очень много вещей, коорые клиент не использует, но может в любой момент использовать. А могу я использовать из командной строки.
vuk (2002-08-21 13:56:00) [14]>Их надо заставить. А если некому будет?
Так Вашим правилам тоже нужно следовать. Определенные требования к клиенту выдвигаются в обоих случаях, просто они разные. Почему и утверждаю - никакой разницы нет.
>Застрахуюсь.
Предположим, что есть такой код(схематично):
DB.StartTransaction;
try
Proc.ExecProc; <- здесь вызов Вашей процедуры
DB.Commit;
except
db.rollback;
raise;
end;
Все, приплыли, имеем шанс заблокировать базу. Код, надо сказать, корректный, а не кривой. Вызов Вашей процедуры завернули в транзакцию на клиенте и вся конструкция уже ничем не отличается от того, что является обычным подходом при написании клиента. Как Вы будете страховаться?
>Как я заставлю людей соблюдать эти правила, если я не могу
>понять, что он там пишет?
Ответственность за соблюдение правил лежит непосредственно на разработчике. Он либо их соблюдает и тогда софт вписывается в существующую инфраструктуру (как он их будет соблюдать - проблема разработчика), либо - нет. Если нет - по рогам ему! :o)
KAA (2002-08-21 13:20:00) [15]>То есть если у Вас клиентская программа при выполнении операции
>с БД зависнет, то ее даже никто прибить не попытается? Или
>машину перезагрузить? Интересная программа... :o)
У нас основная часть пользователей не умеют работать с компьютерами и не хотят уметь. Машину они перезапустят, но не сразу. Снять задачу они не додумаются.
>Кстати, Ваш подход, судя по наличию этой ветки, от такой
>ситуации не страхует не смотря ни на что. Поэтому я и говорю,
>что разницы особой между ними нет.
У меня ошибка в программе, с которой я борюсь. Пока я ее не уберу, программа рабочей не будет.
>Начальству не нравится в первую очередь. Оно достаточно
>технически подковано, чтобы понимать, что HTML и web-browser не
>есть хорошее средство для построения полнофункционального
>клиента БД
Это частный случай вашего предприятия.
У нас технически подкована только компьютерная служба, больше никого.
>Нет. Хорошая разработка должна документироваться.
Это не означает, что люди будут писать по этим правилам. Их надо заставить. А если некому будет?
>>или все толковые люди разбегутся
>Если начальство такое допускает, то это плохое начальство. Такому никакие транзакции не помогут.
Ну допустим повторится август 98го и контора не сможет хорошо платить?
>>Я в этом не разбираюсь, и как я буду контролировать что там аписано?
>Где "там"? В HTML? Так этим server-side приложение должно заниматься. В нем должны соблюдаться общие правила.
Как я заставлю людей соблюдать эти правила, если я не могу понять, что он там пишет?
>От криво написанного клиента все равно не застраховаться.
Застрахуюсь. Если клиент будет глючить, он будет глючить один и не блокировать базу.
>Так что, как я уже написал, это все войны остроконечников с тупоконечниками...
Да вообщем интересно пока.
vuk (2002-08-21 12:50:00) [16]>А кто будет снимать программу?
То есть если у Вас клиентская программа при выполнении операции с БД зависнет, то ее даже никто прибить не попытается? Или машину перезагрузить? Интересная программа... :o)
Кстати, Ваш подход, судя по наличию этой ветки, от такой ситуации не страхует не смотря ни на что. Поэтому я и говорю, что разницы особой между ними нет.
>А вдруг начальству понравится?
Начальству не нравится в первую очередь. Оно достаточно технически подковано, чтобы понимать, что HTML и web-browser не есть хорошее средство для построения полнофункционального клиента БД, несмотря на то, что это местами сейчас модно.
>Это подход типа: я ошибку не допущу
Ничем от Вашего не отличается, т.к. что-то все равно придется писать по правилам.
>А если я уйду с этой работы, то проблемы базы - не мои
>проблемы.
Нет. Хорошая разработка должна документироваться. Далеко не всегда это выполняется, но это способ избежать проблем в будущем.
>или все толковые люди разбегутся
Если начальство такое допускает, то это плохое начальство. Такому никакие транзакции не помогут.
>А вот если начальник в свое время настоял бы на том, чтоб все
>делал сервер,
Ничего бы не поменялось. А сервер все и так делает...
>Я в этом не разбираюсь, и как я буду контролировать что там
>написано?
Где "там"? В HTML? Так этим server-side приложение должно заниматься. В нем должны соблюдаться общие правила.
>А вот написать хранимые процедуры, которые не дудут ему сделать
>лишнее, я могу.
От криво написанного клиента все равно не застраховаться. К тому же Ваш подход для корректной работы тоже требует определенной формы вызова с клиентской стороны - без транзакции. Ибо иначе он ничем от нашего не отличается. При этом надо помнить, что самым распространенным подходом как раз и является явный старт транзакции на клиенте.
Так что, как я уже написал, это все войны остроконечников с тупоконечниками...
KAA (2002-08-21 11:32:00) [17]>Jeer © (21.08.02 10:10)
Да, но может быть один общий стандарт, или два независемых.
Если база может сама обеспечивать свою безопасность, то можно ослабить контроль за написанием клиента.
Тот же дотуп через html. Я в этом не разбираюсь, и как я буду контролировать что там написано? А вот написать хранимые процедуры, которые не дудут ему сделать лишнее, я могу.
Jeer (2002-08-21 10:10:00) [18]Разработка толерантных и робастных (терпимых и устойчивых) сложных систем требует обязательной работы по определенным внутренним стандартам.
Иначе это не разработка, а бардак.
KAA (2002-08-21 09:27:00) [19]>1. Подвисаем до ухода commit на сервер (или отвалился connect)
> - снимаем программу - получаем rollback.
А кто будет снимать программу?
Например я пишу программу для гостиницы, т.е. ее использовать будут 24 часа в сутки 7 дней в неделю. А мы (компьютерная служба) работаем 5 дней в неделю с 9 до 18. Ни горничные, ни кассиры не снимут подвисшую программу. Максимум минут через 20 они надумают перегрузить компьютер. Но в течении этого времени остальные не смогут работать.
>Гм... Сама по себе идея HTML клиента мне мягко говоря не очень нравится.
>Опять же, никто не помешает тому же студенту начать криво писать SP. :o)
Но если если студенту дадут писать только клиента, уже меньше шансов что глюк пропутит.
А вдруг начальству понравится?
>Еще раз объясняю - если кто-то придет в коллектив, он будет
> обязан соблюдать корпоративные стандарты, в том числе и на
> правила вызова SP, поскольку разработка групповая.
У вас все завязано на жестких внутренних правилах. Это подход типа: я ошибку не допущу, и тек то под моим руководством работают тоже не допустят, я проконтролирую. А если я уйду с этой работы, то проблемы базы - не мои проблемы.
(Я уже постучпл по дереву) вдруг у вас изменятся условя работы и все толковые люди разбегутся, а новечки не станут придерживаться ваших правил. А вот если начальник в свое время настоял бы на том, чтоб все делал сервер, горе писатели нового клиента меньше могли бы допустить ошибок.
vuk (2002-08-20 22:19:00) [20]>Ну а ситуация, что в программе произойдет глюк, она подвиснет
>или еще что?
Там две строчки:
ExecProc;
Commit;
1. Подвисаем до ухода commit на сервер (или отвалился connect) - снимаем программу - получаем rollback.
2. А подвиснуть во времяcommit - это надо умудриться... :o) Оно либо в базу уже ушло и значит подтвердило транзакцию либо см. случай 1.
3. Exception в этом блоке - rollback в except. Единственный вариант ошибки - в это время отвалился коннект и невозможно явно вызвать rollback, см. случай 1.
>Кроме того, а вруг кто-нибудь напишет другой клиент. Скажем для
>доступа по html.
Гм... Сама по себе идея HTML клиента мне мягко говоря не очень нравится. Хотя если read-only, то может быть. Но если уж на то пошло, то сам по себе, напрямую, такой клиент все равно в базу не пойдет, а будет реализован как набор server-side приложений. И приложения эти должны быть написаны правильно.
>Мне кажется что технические средства предпочтительней
>административных.
Это средства одного порядка. Просто они находятся в другом месте. Просто в Вашем случае это средство - правильно оформлять SP, а в нашем - правильно их вызывать. Опять же, никто не помешает тому же студенту начать криво писать SP. :o)
>Да он не знает как писать, он пишет как умеет, а умеет плохо.
Еще раз объясняю - если кто-то придет в коллектив, он будет обязансоблюдать корпоративные стандарты, в том числе и на правила вызова SP, поскольку разработка групповая.
| |
Страницы: 