Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Транзакции  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
pkarklin
SET XACT_ABORT ON
<Ненависть>
Пожалуйста, выбирайте любой подход, это ваш выбор.
Но если в продакшине увижу подобное свинское говно - отрублю хвост по самое ...ало.
7 авг 13, 20:50    [14678107]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Упс, как эти пейджи форума меня раздражают, как обычно не в нужном месте разрыв.
7 авг 13, 20:57    [14678126]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
pkarklin, так? Или я вас не понял.
create table tttttt ( f varchar(1000) ) 

go 



create proc Procname1 
as 
begin 
 begin try 
  begin tran 
   insert into tttttt select '1 uroven'
   exec Procname2
  commit tran 
 end try 
 begin catch 
  if XACT_STATE() = -1  rollback tran 
  return 0 
 end catch 
end 

go 

create proc Procname2 
as 
begin 
 begin try 
  begin tran 
   insert into tttttt select '2 uroven'
   exec Procname3
  commit tran 
 end try 
 begin catch 
  if XACT_STATE() = -1  rollback tran 
  return 0 
 end catch 
end 


go 

create proc Procname3 
as 
begin 
 begin try 
  begin tran 
   insert into tttttt select '3 uroven'
   exec Procname4
  commit tran 
 end try 
 begin catch 
  if XACT_STATE() = -1  rollback tran 
  return 0 
 end catch 
end 


go 

create proc Procname4
as 
begin 
 begin try 
  begin tran 
   insert into tttttt select '4 uroven'
    
   select 1/0 
    
  commit tran 
 end try 
 begin catch 
  if XACT_STATE() = -1  rollback tran 
  return 0 
 end catch 
end 

Go 

exec Procname1 
go  
select * from tttttt 
go 
/*
drop proc Procname1
drop proc Procname2
drop proc Procname3
drop proc Procname4

drop table tttttt 
*/
7 авг 13, 21:25    [14678193]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Mnior,

автор
Обана, стандартный троллевский финт ушами.


Внимательно следите, пожалуйста, за тем что я цитирую и на какие "цитаты" задаю вопросы. Троллингом будут считаться все сообщения, в которых ответ на конкретно заданный вопрос будет оформлен в виде "финта ушами".

автор
Т.к. в вянде 3.11 небыло функции X, то её использование назовём лапшёвый говнокод и будем тоталитарно запрещать использовать где либо?
Маразм крепчал.


Можно привести цитату на то, что я где-то кому-то что-то запрещал?

автор
Пока вы не привели ни одного аргумента лапшичности и говнокодовости - т.е. просто сотрясаете воздух.


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

автор
мне вообще от процедурного подхода подташнивает.


Это к доктору. М.б. пилюльку выпишет...

автор
А вот в остальном подход что ни на есть лучший для относительно современных версий скуля.


Жаль, только, что люди, выросшие из "коротких штанишек" Sybase не оценят этот подход. Столько беспричинного кода...

автор
Вот я жалею что игнорировал обсуждения на форуме по шаблонам процедурок и т.п. с подходами, которые были или олдскульные - приводящие к морую кода аля IF @@Error != 0 или имеющие вывернутое нестандартное взаимодействие с клиентом. И явно не так как сейчас советует MS.


Зря игнорировали! Советы MS, предоставляемые вёдрами, следует принимать каплями.

автор
Вот не помню, но то ли опять вы или ктось иной мега-гуру уже нарвались на те же грабли памяти:


Ой, вот ведь пичалька... Не вижу я в сабжевой хп EXECUTE AS OWNER, без которой Вас ожидает:

Msg 2778, Level 16, State 2, Line 1
Only System Administrator can specify WITH LOG option for RAISERROR command.

А с EXECUTE AS OWNER еще и другие чудеса могут приключиться...

автор
Или вы склонны что откат к сейвпоинту для альтернативных действий (вместо полного отката транзакции) встречается намного чаще?


Я (пока) не вижу причин что-то делать и откатываться к сейвпоинту для предпринятия альтернативных действий. Пример из жизни приведите, уже.

автор
И как 30-й уровень бизнес логики сможет выполнить альтернативное действие при ошибке этой грёбаной SomeProc, если она куяк и "откатит транзакцию по самые помидоры и прервет бач"?
Ваша процедура ломает логику вышестоящих уровней напроч.


Какая-такая вышестоящая логика, если Core проца на 31 уровне при переводе средств со счета на счет Вам сказала: "А вот куй!"?!
7 авг 13, 21:41    [14678225]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Mnior
<Ненависть>


Видимо, у нас разная трактовка термина "бизнес-транзакция"...
7 авг 13, 21:42    [14678227]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Cammomile,

Что это?! Если мои разработчики будут тратить время на писание такого кода, среди которого только 5% продуктивного, то им придется искать другое место работы.
7 авг 13, 22:13    [14678311]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
pkarklin
Внимательно следите, пожалуйста, за тем что я цитирую и на какие "цитаты" задаю вопросы.
А почему должен толь я следить (что видимо только я и делаю), а вы вот нет? Вы на что отвечали своим "вопросом" на какой мой аргумент?
Как мне реагировать на вопросы типа "Перестали ли вы пить вотку по утрам?"?
pkarklin
в которых ответ на конкретно заданный вопрос будет оформлен в виде "финта ушами".
Ваша задача меня развести на бан? Серьёзно спрашиваю.
Для этого не надо тролить (по другому я не могу интерпретировать ваши действия, ибо считаю вас умным человеком), а просто сказать в лицо.
pkarklin
автор
Т.к. в вянде 3.11 небыло функции X, то её использование назовём лапшёвый говнокод и будем тоталитарно запрещать использовать где либо?
Маразм крепчал.
Можно привести цитату на то, что я где-то кому-то что-то запрещал?
Туто 14677212:
pkarklin
но сабжевый говнокод на Production никогда не выпущу.

pkarklin
Для признания сабжевого кода лапшеоборазным нет необходимости в какой-либо аргументации
Для признания как раз нужно, а вот для собственного неприятия не нужно.
pkarklin
Впрочем, я так и не увидел аргументов в его поддержку.
Просто надо читать мои посты, повторюсь:
- TRY/CATCH избавляет от спама IF @@Error после каждой команды
- SAVE POINT + :
-- для альтернативных действий
-- целостность блока и независимость от выше/ниже стоящих
-- не нарушает чужую логику

Так мне доказывать что я не верблюд, или всё-таки вам отвечать за свои слова?
pkarklin
Советы MS, предоставляемые вёдрами, следует принимать каплями.
Ждал этого плевка в мою сторону - словно я тут первый раз на форуме и вы, pkarklin, словно меня не знаете, и разводите меня на нуба.
Фиолетово, на этот детсад.
pkarklin
Ой, вот ведь пичалька... Не вижу я в сабжевой хп EXECUTE AS OWNER, без которой Вас ожидает:
Не поверите - всё тот же, в том же месте 14673090 пресловутый кривой C&P, а именно вырезание "подробностей".
Так вот, вы то писали 14672170 что "пичалька" в самом WITH LOG, а не его использовании без EXECUTE AS. Так что увы и ах.
pkarklin
А с EXECUTE AS OWNER еще и другие чудеса могут приключиться...
Никто не сомневается что вы гуру - этого доказывать "по ходу" мне и другим не надо.
pkarklin
Я (пока) не вижу причин что-то делать и откатываться к сейвпоинту для предпринятия альтернативных действий. Пример из жизни приведите, уже.
Вот! Тут и проявляются знания, точнее опыт. :)
Ок, возьмём с потолка пример в отрыве от всего: Проведение карточной операции через процессинг.
Думаю вы догадались что к чему, хотя я склонен к тому что вы итак знали про этот класс задач, про которые я выше и писал 14673090:
Mnior
Вы то думаете что существует, лять, одна целая ундер-транзакция, ага, на все сервисы мира. Уяк и сразу откатило пол мира с разными подходами и стратегиями проведения операций.
И да - аргумент типа "карточный процессинг и скуль не совместим" - не катит:
1. Совместим, очень даже
2. Я хочу показать класс задач, придираться к частностям нет смысла
3. На то кстати и Брокер - сложная логика и внешнее взаимодействие подразумевается.

автор
Какая-такая вышестоящая логика, если Core проца на 31 уровне при переводе средств со счета на счет Вам сказала: "А вот куй!"?!
И вот и делаем - откатываем всё своё - не только в базе но и во внешних системах к примеру, а не прерываем батч и пиши пропало. Мочало - начинай-ка всё с начала?! - офигеть эффективность.
А вот если куяк и сказала просто "не хорошо", то это не уже не звездец, а просто надо сделать что-то другое и возможно провести это дальше до самых помидор.
На то она и бизнес логика и на то она Enterprise - что какая хошь, а не какой-то 95%-ый Standard или Express.

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

Так что надо понимать, что шаблон это Enterprise необходимость, не гарантирующий что это всё-таки было необходимо, но гарантирующий применимость (без переписывания) "на горячее" под любое решение.
В остальных 95% или нет процедур вообще или они топорные пробки.

Давайте я ещё за вас ходы просчитаю:
- Но правильно реализовать транзакционную оболочку по внешние сервисные операции, чтобы на откат просто проводились сооветсвующие действия. И также со всем контролем сбоев.
- Вы правы - это сильно облегчит код, НО:
1. Стоит ли овчинка выделки?
2. Надо иметь знания как реализовать оный интерфейс.
- Неужто легко его оформить и поддерживать, как какой-нидь линкед? (оракакл говорит об обратном)
- Насколько он гибок?
3. IMXO Не всякое решение можно впихнуть в линейную транзакционность.
4. Может приводить к злоупотреблению.
SB, кпримеру, более гибок и не надо подстраиваться - и прямо рядом вся реализация - никакого хардкора.
pkarklin
Видимо, у нас разная трактовка термина "бизнес-транзакция"...
Нет, видимо кто-то не понимает что транзакция это частный случай, частное решение и со внешними сервисными решениями это скорее исключение чем правило.
А частное никогда не доказывает общное.

pkarklin
ибо он лапшеобразен по своей сущности
Веский и понятный аргумент.
pkarklin
Жаль, только, что люди, выросшие из "коротких штанишек" Sybase не оценят этот подход. Столько беспричинного кода...
Поматросил и бросил. Линки кидайте, а то кроме вас шютку никто не поймёт.
pkarklin
Если мои разработчики будут тратить время на писание такого кода, среди которого только 5% продуктивного, то им придется искать другое место работы.
Шаблон на то и шаблон - что не набирается руками, а появляется автоматом.
А то что 95% упакованного сложного бизнес кода было выпилено и осталось кожура - не даёт вам аргументировать про 5% продуктивности.
Да, в большинстве своём процедуры современных "кодеров" наполнены смыслом отсилы на 5%, но большую часть составляют не столько шаблоны - сколько излишние преобразования из пустого в порожнее, и размазывание простой операции на 100500 шагов - ибо "так им понятнее".

"лапшеобразен", "беспричинный", "тратить время на писание кода" - вы абсолютно правы. На то я и писал много раз на форуме про отсутствие нормальных механизмов и семантической структуры у современного парка RDBS. Многое кажется не решением, а костылями.
Поэтому я упоминал про "нативное наличие транзакции в триггерах" (очень давно), сетовал на оператор ATOMIC 14482179 и т.п.

PS: Конечно "спорить" с админом форума чревато, но я сетую что любой админ должен быть со стальными нервами, холодной головой и быть полной противоположностью тролю.
8 авг 13, 01:42    [14678844]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Mnior
В том-то и прикол - что данные процки должы работать для любого подхода используемого сверху.
И для ундер-гига-транзакций и для итеративного сервисного обслуживания с множествами своих микротранзакций.

Прикол в том, что для "ундер-гига-транзакций" эти "процки" работать не будут.
Ибо
'
Msg 627, Level 16, State 1, Procedure XXX, Line YYY
Cannot use SAVE TRANSACTION within a distributed transaction.
Msg 3998, Level 16, State 1, Line ZZZ
Uncommittable transaction is detected at the end of the batch. The transaction is rolled back.
'

Так что шаблон из первого поста темы отнюдь не универсален.
8 авг 13, 08:40    [14679106]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
автор
что это

pkarklin, концепт

Если основа" бизнес идеи" "всё либо ничего", то надо просто писать все процедуры по шаблону. Если эррор(чего, я правда не указал) либо непредвиденный случай и транзакция "протухал" то роллбек и ретурн 0.

И так свкозь всю цепочку вызова.

Где я не прав?

автор
Если мои разработчики будут тратить время

А у нас используется SQL Prompt и шаблоны процедур. Очень удобно.
8 авг 13, 09:16    [14679215]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Cammomile
create proc Procname1 
as 
begin 
 begin try 
  begin tran 
   insert into tttttt select '1 uroven'
   exec Procname2
  commit tran 
 end try 
 begin catch 
  if XACT_STATE() = -1  rollback tran 
  return 0 
 end catch 
end 
go 

Выделенный код откатывает транзакцию даже в том случае, если она началась снаружи процедуры. Поэтому с таким подходом тут же нарвёмся на ошибку "Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0."
8 авг 13, 09:40    [14679307]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31431
Cammomile
Если основа" бизнес идеи" "всё либо ничего", то надо просто писать все процедуры по шаблону. Если эррор(чего, я правда не указал) либо непредвиденный случай и транзакция "протухал" то роллбек и ретурн 0.

И так свкозь всю цепочку вызова.

Где я не прав?
Я не вижу смысла плодить сущности сверх необходимого. Да, этот шаблон работающий, но зачем он именно такой?
Mnior
pkarklin
SET XACT_ABORT ON

<Ненависть>
Пожалуйста, выбирайте любой подход, это ваш выбор.
Но если в продакшине увижу подобное свинское говно - отрублю хвост по самое ...ало.
Неприятно видеть в каждом посте флаг "все вокруг тролли". Или как, бывает только два мнения - ваше и неправильное? :-)

Идеология T-SQL, управление ошибками (до 2012), текущее управление транзакциями, отсутствие полноценных табличных параметров в процедурах и многое другое подсказывают мне, что самое оптимальное решение - SET XACT_ABORT ON или проверки "if @@error <> 0 goto обработчик ошибок" после каждого стейстмента.
Cammomile
pkarklin, так? Или я вас не понял.
insert ... exec ... не может быть вложенным. Это вообще плохо работающая конструкция по многим причинам, не наджо её использовать, только из безисходности.
8 авг 13, 09:42    [14679316]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Гость333, вы запускали код целиком? В конкретно данном случае ошибки нет.
с SELECT 1/0 все откатывается "по самые помидоры"
без SELECT 1/0 в таблице ожидаемые 4 записи. Полный успех, не ?

И вообще, это же концепт, почти копия примера из БОЛ
8 авг 13, 09:50    [14679352]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Гость333
Member

Откуда:
Сообщений: 3683
alexeyvg
Идеология T-SQL, управление ошибками (до 2012), текущее управление транзакциями, отсутствие полноценных табличных параметров в процедурах и многое другое подсказывают мне, что самое оптимальное решение - SET XACT_ABORT ON или проверки "if @@error <> 0 goto обработчик ошибок" после каждого стейстмента.

Хм, а что не так с управлением ошибками в 2005...2008R2? TRY...CATCH есть, RAISERROR есть. Что принципиально поменялось в 2012?

alexeyvg
Cammomile
pkarklin, так? Или я вас не понял.
insert ... exec ... не может быть вложенным. Это вообще плохо работающая конструкция по многим причинам, не наджо её использовать, только из безисходности.

Если присмотреться внимательно, то никаких insert-exec там нет :-)
   insert into tttttt select '3 uroven'
   exec Procname4

Но загримировано под insert-exec вполне качественно, согласен.
8 авг 13, 09:52    [14679367]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
alexeyvg
insert ... exec ... не может быть вложенным. Это вообще плохо работающая конструкция по многим причинам, не наджо её использовать, только из безисходности.


Я не использую конструкцию insert-exec
8 авг 13, 09:54    [14679373]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Cammomile
Гость333, вы запускали код целиком? В конкретно данном случае ошибки нет.
с SELECT 1/0 все откатывается "по самые помидоры"
без SELECT 1/0 в таблице ожидаемые 4 записи. Полный успех, не ?

И вообще, это же концепт, почти копия примера из БОЛ

Запускал. С небольшой модификацией — обернув вызов Procname1 в транзакцию:
begin tran
exec Procname1 
commit

Полного успеха не обнаружил.
8 авг 13, 09:54    [14679374]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31431
Cammomile
alexeyvg
insert ... exec ... не может быть вложенным. Это вообще плохо работающая конструкция по многим причинам, не наджо её использовать, только из безисходности.


Я не использую конструкцию insert-exec
Это был просто комментарий к 14678193
Гость333
Хм, а что не так с управлением ошибками в 2005...2008R2? TRY...CATCH есть, RAISERROR есть. Что принципиально поменялось в 2012?
Ну там хотя бы THROW добавился...
8 авг 13, 09:55    [14679381]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31431
alexeyvg
Cammomile
Я не использую конструкцию insert-exec
Это был просто комментарий к 14678193
А, блин, неправильно прочитал текст примера :-)
8 авг 13, 09:56    [14679383]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
alexeyvg
Я не вижу смысла плодить сущности сверх необходимого. Да, этот шаблон работающий, но зачем он и .


В моей картине мира, это стандартный подход к решению задачи "откатить всё, если в глубине вызовов есть эррор"

Что вам конкретно не по душе?Повторюсь, фактически, это пример из БОЛ.

Как вы решите задачу "выполнить ряд вложенных процедур, откатить ВСЁ, если ошибка на энном уровне вложенности"?


PS
В отличие от суровой разборки между более опытными коллегами, я просто пытаюсь найти максимум новых подходов. Ни в коем случае не тролль.
8 авг 13, 10:00    [14679402]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
Гость333, аргумент вы очень хороший привели.
Гость333
Прикол в том, что для "ундер-гига-транзакций" эти "процки" работать не будут.
Ибо
'Cannot use SAVE TRANSACTION within a distributed transaction.'

Так что шаблон из первого поста темы отнюдь не универсален.
Поправлю - вместо "работать не будут", "будут работать не всегда". Ок?!
К тому же как раз проблема ТС была также фатальна, 14671675:
MaxiMaxiM
'Невозможно использовать инструкцию ROLLBACK внутри инструкции INSERT-EXEC.'

Универсальных шаблонов не бывает. Точнее абстракции протекают.
Но это не означает что надо всё бросить и пойти ужраться. Верно?
Для любого подхода найдётся задача, которая не по зубам.

Давайте отойдём от когнитивного искажения и не будем приписывать мне "Mnior нашёл экстра-пупер универсальное решение". Ок?! А поборемся от "Ага сказали сибирские мужики и поменяли бензопилу на топор" и "а давайте обобщим чужое - будем считать что все процедуры так написаны".

Распределёнки имеют кучу косяков, их бывает тяжело вообще завести и поддерживать (привет оракакл).
Поэтому я их недолюбливаю, поэтому иногда используешь иные механизмы (сервисное решение).

И к тому же я писал:
Mnior
..., а не прерываем батч и пиши пропало. Мочало - начинай-ка всё с начала?! - офигеть эффективность.
...
А вот с падением сессии/сервера это правильный аргумент в этой цепочке рассуждений. Но он показывает сложность написания системы и её разнообразие, а не контр-аргумент.
... никак не отменяет использование скулевых транзакций и предварительных действий.
Из-за падений надо фигачить механизмы "восстановления". Но это не означает что надо все сбои на них взваливать (пресловутым чуть что - ахтуг сессии), когда в 95% случаев откатов можно тут же всё разрулить по быстрому.

И вы понимаете почему сайвпоинты не работают в распределёнках?
8 авг 13, 10:02    [14679413]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Гость333
Cammomile
Гость333, вы запускали код целиком? В конкретно данном случае ошибки нет.
с SELECT 1/0 все откатывается "по самые помидоры"
без SELECT 1/0 в таблице ожидаемые 4 записи. Полный успех, не ?

И вообще, это же концепт, почти копия примера из БОЛ

Запускал. С небольшой модификацией — обернув вызов Procname1 в транзакцию:
begin tran
exec Procname1 
commit

Полного успеха не обнаружил.

Спасибо, я подумаю.
8 авг 13, 10:04    [14679422]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg
Неприятно видеть в каждом посте флаг "все вокруг тролли".
Ну, может стоит подумать о смене принципа комментирования? :)
alexeyvg
Или как, бывает только два мнения - ваше и неправильное? :-)
Это уже мне стоит подумать о смене принципа комментирования. Но я воспринимаю разговор как тестовый полигон прогнать идею, точнее верность формализма. А не как установить уровень социальной иерархии.
Наше общее дело относится ко всему скептически, чтоб помочь друг другу.
Поэтому я склонен к задротному стилю КО с выбешивающим описанию деталей, чем к тонким подколкам/намёкам.
alexeyvg
Идеология T-SQL, управление ошибками (до 2012), текущее управление транзакциями, отсутствие полноценных табличных параметров в процедурах и многое другое подсказывают мне, что самое оптимальное решение - SET XACT_ABORT ON
Я тоже начал с него, но в итоге мне пришлось отказаться.
И вообще меня XACT_ABORT прибешивает тем что его нельзя контролировать.
Если код написан в надежде на него, то кто-то может его сломать лёгким движением SET и вот тогда клобзец реальный.
alexeyvg
или проверки "if @@error <> 0 goto обработчик ошибок" после каждого стейстмента.
И вот это не такой же лапшекод?
Cammomile
В моей картине мира, это стандартный подход к решению задачи "откатить всё, если в глубине вызовов есть эррор"
Это самый что ни на есть нормальный повсеместный подход.
Только есть одно но - это пресловутое "всё".
1. Ошибка далеко не затрагивает всё, а только какой-то логический кусок.
2. Всё у вас не получится , к примеру дойдёт до апликешин сервера, которому фиолетово на ваше "всё" и он сделает то, что заложено в его бизнес логике.
Расширьте восприятие картины.

Гость333 подвёл к правильному ракурсу проблемы и интересной теме. Отличный шанс для формализации и выправлении искажений восприятия.

Также стандартным подходом можно назвать что большая часть логики лежит на апликешн сервере (AS). Он является тем цементом, который сшивает всевозможные подходы, сервисную и транзакционную модели/интерфейсы.

И вот тут я решил попробовать использовать вывернутую модель. Когда скуль использует AS и является первоисточником/основанием.
Ссори что выхожу за тематику топика (уже который раз )
Если вы скажете что я решил перейти на неё из-за неправильной архитектуры AS и надо было использовать другую, то я возможно соглашусь, но потребую описать/сослаться на "правильное" построение всей системы.

Гость333, подвёл к тому что транзакционность плохо работает, плохо реализована особенно для сложных распределённых систем (ненависть к корпоративному зоопарку). Хотя по своей сути она зиждиться на тех же определённых правильных порядков действий, это всего лишь программный интерфейс облегчающий процесс, но не панацея.

Как мы понимаем - полноценные вложенные транзакции или сейвпоинты это теже яйца только в ан фаз/профиль. И что это иногда вынужденная необходимость и только это реализует подход модульной независимости. И то что текущая реализация распределёнок это ломает. Поэтому я перестал называть её полноценным решением, в довесок к тому паровозу граблей межсерверного взаимодействия.
Поэтому всё локальное стараюсь консолидировать в одно место (локальные транзакции), а всё внешнее больше считать как сервисные системы (ветвистые цепочки взаимодействия).
Тем самым устраняем данный класс проблем взаимодействия и сделав его контролируемым. Оставим кактус для мышей.

Надёжность и однообразие скуля подталкивает его как хранителя основной/массовой бизнес логики, а всё остальное как независимые кусочки, отлаженных сервисов, локализующие каждый свои болезни, оберегая от них основную систему.
Т.к. внешнее взаимодействие требует сохранения чего-то в RDBS, то в данном случае всё "по рукой" в отличие от AS.

Да, автономные транзакции вещь скорее полезная и хотелось видеть в скуле. И она же костыльно реализуется то.
8 авг 13, 12:37    [14680546]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Гость333
Member

Откуда:
Сообщений: 3683
alexeyvg
Гость333
Хм, а что не так с управлением ошибками в 2005...2008R2? TRY...CATCH есть, RAISERROR есть. Что принципиально поменялось в 2012?
Ну там хотя бы THROW добавился...

Вот честно, не понимаю, что такого можно сделать при помощи THROW, чего нельзя было бы сделать при помощи RAISERROR. Да, из блока CATCH "лёгким движением руки" можно перевыбросить исключение с сохранением всех деталей. При использовании RAISERROR придётся немного поднапрячься, запрашивая error_severity, error_message и прочее. Но это всё равно несравнимо легче, чем после каждого чиха (которых в каждой процедуре может быть ой как много) проверять значение @@ERROR.

Mnior
Гость333
Прикол в том, что для "ундер-гига-транзакций" эти "процки" работать не будут.
Ибо
'Cannot use SAVE TRANSACTION within a distributed transaction.'

Так что шаблон из первого поста темы отнюдь не универсален.

Поправлю - вместо "работать не будут", "будут работать не всегда". Ок?!

Ммм... тут вопрос терминологии. Если необходимым атрибутом "ундер-гига-транзакции" является её распределённость, то процедуры "не будут работать всегда". Если же "ундер-гига-транзакция" может быть не распределённой, то "будут работать не всегда", ок :-)

Mnior
И вы понимаете почему сайвпоинты не работают в распределёнках?

Не понимаю :-(
Вот оказалось, что когда-то сейвпойнты работали: INF: Limited Support for Savepoint in Distributed Transactions in SQL Server 2000 Service Pack 1.
Microsoft
To allow application migration from Microsoft SQL Server 6.5 when savepoints inside distributed transactions are in use, Microsoft SQL Server 2000 Service Pack 1 introduces a trace flag that allows a savepoint within a distributed transaction.

Наверняка была какая-то веская причина для запрета сейвпойнтов, может, даже описанная в каком-нибудь блоге разработчиков Microsoft. Но сходу я не нашёл такую информацию.

Mnior
К тому же как раз проблема ТС была также фатальна, 14671675:
MaxiMaxiM
'Невозможно использовать инструкцию ROLLBACK внутри инструкции INSERT-EXEC.'

Тут да, какая-то недоработка со стороны Microsoft. С одной стороны, вот вам функция XACT_STATE, если её значение равно 1, то делайте с транзакцией что хотите: хоть коммит, хоть роллбэк, хоть сейвпойнт, хоть откат к сейвпойнту. С другой стороны, даже если XACT_STATE = 1, нас могут подстерегать то распределённая транзакция, то INSERT-EXEC, то (наверное) ещё какая-нибудь неведомая хрень. То есть текущих трёх возможных значений XACT_STATE явно недостаточно.

Cammomile
Спасибо, я подумаю.

Могу предложить, например, такой шаблон. Это если я правильно понял, что вам нужно.
create procedure XXX
as
begin try
   declare @trancount int;
   set @trancount = @@trancount;
   if @trancount = 0
      begin transaction;
   ...
   if @trancount = 0
      commit transaction;
end try
begin catch
   if @trancount = 0
      rollback transaction;
   throw;
end;
go
9 авг 13, 08:54    [14684798]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
StarikNavy
Member

Откуда: Москва
Сообщений: 2396
Конгресс, немцы (зачеркнуто) транзакции какие-то . Голова пухнет. Взять все - да и поделить (зачеркнуто) откатить!
9 авг 13, 09:29    [14684962]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Гость333, Да - да. Я уже и сам так переписал +- перламутровые пуговки, да не было времени тут запостить.

В общем я имел в виду, что , насколько я в курсе, задача "получиться всё или откатить всё" вполне решаема при помощи инструкций TSQL и написания хранимок по определенному выверенному шаблону.

Пишем ли мы If @@Error или If @@Trancount не или прочие шаманства -- уже детали.
9 авг 13, 10:30    [14685340]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31431
Гость333
Могу предложить, например, такой шаблон.
create procedure XXX
as
begin try
   declare @trancount int;
   set @trancount = @@trancount;
   if @trancount = 0
      begin transaction;
   ...
   if @trancount = 0
      commit transaction;
end try
begin catch
   if @trancount = 0
      rollback transaction;
   throw;
end;

Вот я собственно так и делаю. Если транзакцию начала процедура, то ей её и завершать. Если снаружи, пусть завершают там. Клиент обязан при получении ошибки проверить и откатить транзакции (если он не закрывает коннект). Накаких XACT_STATE, никаких точек сохранения...
Гость333
Вот честно, не понимаю, что такого можно сделать при помощи THROW, чего нельзя было бы сделать при помощи RAISERROR. Да, из блока CATCH "лёгким движением руки" можно перевыбросить исключение с сохранением всех деталей. При использовании RAISERROR придётся немного поднапрячься, запрашивая error_severity, error_message и прочее.
Неприятно, что не сохраняется номер ошибки.
Какое то неполноценное пробрасывание ошибки наверх.
Гость333
Но это всё равно несравнимо легче, чем после каждого чиха (которых в каждой процедуре может быть ой как много) проверять значение @@ERROR.
Ну конечно, обработчик ошибок это хорошо. Просто реализация ужасная, за 10-15-20 лет не могли реализовать простейшей и необходимейшей функциональности :-(
StarikNavy
Взять все - да и поделить (зачеркнуто) откатить!
+1
Глупо расчитывать на то, что десятки лет завод для сопровождения и развития системы будет держать целый отдел Преображенских. Проще нужно быть, и люди к вам потянутся :-)
9 авг 13, 10:40    [14685393]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить