Коллеги, что вы думаете о данном коде? 2MikeR

[Vadik]

Цитата:

Сообщение от belugin

тут вся загвоздка в слове necessary - устраивает ли тебя если в случае проблем с сетью половина строк обновится, а половина, нет

Или - готов ли ты поставить всю систему в интересную позу на продолжительное время блокировками на время обновления в одной транзакции и (если не срастется) повторять пока не получится

[belugin]

Цитата:

Сообщение от Vadik

Или - готов ли ты поставить всю систему в интересную позу на продолжительное время блокировками на время обновления в одной транзакции и (если не срастется) повторять пока не получится

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

[Vadik]

Цитата:

Сообщение от belugin

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

Давайте для экономии времени будем исходить из того что разработчик по умолчанию знает что в данном случаем является минимальным скопом для транзакции (прошу прощения за англицизмы) и спор лишь о том стоит ли стараться придерживаться его в разработке или писать "как проще" - "ttsbegin в первой строке, ttscommit в последней" Я как человек который в итоге отвечает за весь инстанс в целом привык требовать чтобы код оттестированный в разработческой среде можно было запускать в продуктиве без переписывания (мелкие транзакции), бог весть чего в последний момент "наоптимизируют", но готов выслушать альтернативные точки зрения

[belugin]

Цитата:

Сообщение от Vadik

Давайте для экономии времени будем исходить из того что разработчик по умолчанию знает что в данном случаем является минимальным скопом для транзакции

Давайте исходить из предложенного примера. MikeR,
- что произойдет, если нерадивый админ кильнет aos32 на середине процесса обновления таблицы? (случится креш аоса, пропадение связи и прочее - кстати, код на сервере выполняется?)
- что произойдет если два пользователя запустят этот процесс одновременно
- используется ли на изменяемой таблице оптимистичная или пессимистичная блокировка и как измениться поведение "совсем уж мелких деталей" при этом.

P.S. По моему опыту есть некий оптимум по скорости обновления записей и он может находиться где-то между "все записи сразу" и "каждая запись отдельно". Т.е. может быть более выгодно обновлять пакетами по n записей.

[MikeR]

2belugin я почему открыл обсуждение, что ОПТИМИСТИЧЕСКАЯ МОДЕЛЬ НЕ СОГЛАСУЕТСЯ С ЦЕЛОСНОСТЬЮ, даже inventTrans оптимистический. И ведомые языческами богами других систем народ продавливает производительность. Или давайте возвращаться к писиместической модели, и тогда код написанный нерадивым коллегой будет корректен. Почему нерадивым -у него посто куча разных ляпов, ключевое поле guid, допустим, об осталном уже писал. Он просто пытался подделать то, что знал из другой системы в аксапту. А здесь другая религия. Никто к пессимизму не вернется, так как по производительности будет полный провал. Хотя стоит отметить есть и другие реализации, но их мало.

[belugin]

Цитата:

Сообщение от MikeR

2belugin я почему открыл обсуждение, что ОПТИМИСТИЧЕСКАЯ МОДЕЛЬ НЕ СОГЛАСУЕТСЯ С ЦЕЛОСНОСТЬЮ

Расшифруй?

Цитата:

Никто к пессимизму не вернется, так как по производительности будет полный провал.

Это завсит от вероятности коллизии на конкретной таблице. (Знаешь, почему одна модель называется оптимистической, другая пессимистической)?

[MikeR]

Цитата:

Сообщение от belugin

Расшифруй?

Там, кстати по SQL север где ссылку положили есть такое определение:
" Если пользователь пытается изменить строку, то ее текущие значения сравниваются со значениями, полученными во время последней выборки этой строки. Если какое-либо значение изменилось, то сервер определяет, что другой пользователь или процесс уже обновил эту строку, и возвращает ошибку. Если значение остается прежним, то сервер выполняет изменение."
http://technet.microsoft.com/ru-ru/l...ql.105%29.aspx
В писсимистичесой модели все становятся в очередь и терпиливо ждут первый процесс, ну или какой там тормозит. Вот это я и имел в виду, что писсимистическая в плане целостности лучше работает, чем оптимистическая. То есть оптимистическая абортирует затормозившие процессы, без стыда и совести.