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

[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
В писсимистичесой модели все становятся в очередь и терпиливо ждут первый процесс, ну или какой там тормозит. Вот это я и имел в виду, что писсимистическая в плане целостности лучше работает, чем оптимистическая. То есть оптимистическая абортирует затормозившие процессы, без стыда и совести.

[Vadik]

Цитата:

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

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

Специальный тип исключения UpdateConflict и макрос OCCRetryCount в системе для красоты живут, надо полагать ?

[belugin]

Цитата:

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

. То есть оптимистическая абортирует затормозившие процессы, без стыда и совести.

В этом случае предлагается повторить транзакцию.

У тебя свое определение целостности.

http://en.m.wikipedia.org/wiki/Consi...tabase_systems)

In database systems, a consistent transaction is one that starts with a database in a consistent state and ends with the database in a consistent state. Consistent state means that there is no violation of any integrity constraints. Consistency may temporarily be violated during execution of the transaction, but must be corrected before changes are permanently committed to the database. If the transaction would leave the database in an illegal state, it is aborted and an error is reported.[1]