22.01.2014, 22:12 | #21 |
MCT
|
Правильно ли я тебя понимаю, что когда, допустим в разноске надо обновить два десятка таблиц и вставить в еще пару десятков, то методологически правильно открывать ОДНУ транзакцию, вешать блокировку while select forupdate по обновляемым таблицам? Иначе тоже может произойти пук и мы потеряем целостность, то есть запишем в таблицу налогов одни цифири, а допустим документы не обновим.
__________________
Axapta book for developer |
|
22.01.2014, 22:21 | #22 |
Участник
|
Вот ещё интересная реализация Модификация огромного количества (сотни тысяч) записей в Axapta 3.0 SP4
|
|
23.01.2014, 07:39 | #23 |
MCT
|
Цитата:
Сообщение от S.Kuskov
Вот ещё интересная реализация Модификация огромного количества (сотни тысяч) записей в Axapta 3.0 SP4
Целостьность, которую ставили выше всего так же страдает!! ЗЫ может именно поэтому двенашка так сильно тормозит по сравнению с девяткой Однако, политкорректненько вы плюсы раздаете
__________________
Axapta book for developer Последний раз редактировалось MikeR; 23.01.2014 в 07:42. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (2). |
23.01.2014, 08:12 | #24 |
NavAx
|
Насколько я понимаю, именно в этом смысл транзакции и есть.
__________________
Isn't it nice when things just work? |
|
23.01.2014, 08:47 | #25 |
Участник
|
Цитата:
И даже здесь возникает дилемма, что лучше заблокировать два десятка таблиц на 5 минут и гарантированно выполнить разноску? Или пересчитывать постоянно меняющиеся данные до посинения? Это уже организационный вопрос и решать его нужно организационными методами. Например, если оперативность разноски не критична, то выносить такую разноску в пакетное задание на ночь. |
|
23.01.2014, 08:56 | #26 |
Участник
|
Примеры архитектурных решений:
Целостность данных при длительных запросах Kurt Hatlevik: Review of inventory II |
|
23.01.2014, 08:57 | #27 |
MCT
|
Цитата:
Сообщение от S.Kuskov
И даже здесь возникает дилемма, что лучше заблокировать два десятка таблиц на 5 минут и гарантированно выполнить разноску? Или пересчитывать постоянно меняющиеся данные до посинения? Это уже организационный вопрос и решать его нужно организационными методами. Например, если оперативность разноски не критична, то выносить такую разноску в пакетное задание на ночь.
__________________
Axapta book for developer |
|
23.01.2014, 09:03 | #28 |
MCT
|
Цитата:
Сообщение от S.Kuskov
Примеры архитектурных решений:
Целостность данных при длительных запросах Kurt Hatlevik: Review of inventory II Я это к тому, что и оптимистическая модель, так же не согласуется с целостностью. Первый держащий блокировку процесс идет лесом, какая уж тут согласованость и целостность. Однако тренд ныне популярный.
__________________
Axapta book for developer Последний раз редактировалось MikeR; 23.01.2014 в 09:06. |
|
23.01.2014, 09:40 | #29 |
Участник
|
Цитата:
- что произойдет, если нерадивый админ кильнет aos32 на середине процесса обновления таблицы? (случится креш аоса, пропадение связи и прочее - кстати, код на сервере выполняется?) - что произойдет если два пользователя запустят этот процесс одновременно - используется ли на изменяемой таблице оптимистичная или пессимистичная блокировка и как измениться поведение "совсем уж мелких деталей" при этом. P.S. По моему опыту есть некий оптимум по скорости обновления записей и он может находиться где-то между "все записи сразу" и "каждая запись отдельно". Т.е. может быть более выгодно обновлять пакетами по n записей. |
|
23.01.2014, 10:43 | #30 |
MCT
|
2belugin я почему открыл обсуждение, что ОПТИМИСТИЧЕСКАЯ МОДЕЛЬ НЕ СОГЛАСУЕТСЯ С ЦЕЛОСНОСТЬЮ, даже inventTrans оптимистический. И ведомые языческами богами других систем народ продавливает производительность. Или давайте возвращаться к писиместической модели, и тогда код написанный нерадивым коллегой будет корректен. Почему нерадивым -у него посто куча разных ляпов, ключевое поле guid, допустим, об осталном уже писал. Он просто пытался подделать то, что знал из другой системы в аксапту. А здесь другая религия. Никто к пессимизму не вернется, так как по производительности будет полный провал. Хотя стоит отметить есть и другие реализации, но их мало.
__________________
Axapta book for developer |
|
23.01.2014, 11:14 | #31 |
Участник
|
Цитата:
См. также давнишнюю статью Fed'а про то, как избегают блокировок в inventory |
|
23.01.2014, 11:16 | #32 |
Участник
|
Цитата:
Цитата:
Никто к пессимизму не вернется, так как по производительности будет полный провал.
|
|
23.01.2014, 12:04 | #33 |
Участник
|
Цитата:
Сообщение от MikeR
Для карсоты решения еще раз приведу утверждения
5 Корректный код X++: while select ItemId from salesLine { select firstOnly forUpdate ItemType, ItemBuyerGroupId from inventTable where inventTable.ItemId == salesLine.ItemId; If (inventTable && (inventTable.ItemType == InventItemType::Item)) { ttsBegin; inventTable.ItemBuyerGroupId = ; inventTable.update(); ttsCommit; } } X++: while select ItemId from salesLine join inventTable where inventTable.itemid == salesLine.itemId && inventTable.ItemType == InventItemType::Item { update_recordset inventTableUpd setting inventTableUpd.ItemBuyerGroupId = where inventTableUpd.ItemId == salesLine.ItemId; } Объединение множественных обновлений в одну транзакцию - это конечно блокировки - но более производительный вариант для БД ИХМО. Последний раз редактировалось someOne; 23.01.2014 в 12:09. |
|
|
За это сообщение автора поблагодарили: mazzy (2), MikeR (3). |
23.01.2014, 13:17 | #34 |
MCT
|
someOne хороший варинат, если покурсовый не перекрыт.
__________________
Axapta book for developer |
|
23.01.2014, 13:58 | #35 |
Участник
|
|
|
23.01.2014, 14:08 | #36 |
Moderator
|
|
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
23.01.2014, 14:25 | #37 |
Участник
|
Определение транзакции уже дает ответ на данный вопрос. И если каждое действие зависит от предыдущего - тогда делаем в одной транзакции, а если действия независимы - то какая разница? Произойдет бум в середине изменения состояния независимых записей - ну и ладно. Запустим заново и доделаем (в идеале, механизм проверки должен быть), иначе, транзакция по полной программе - зато данные в порядке.
То есть, сейчас вы спорите просто о том, кто и как для себя видит 1 единицу действия сферического коня в вакууме... Ответ на вопрос зависит только от предпочтений и опыта программиста в в каждом конкретном случае. |
|
24.01.2014, 03:23 | #38 |
Талантливый разгвоздяй
|
ИМХО:
About locking and blocking in Dynamics AX and how to prevent it |
|
24.01.2014, 07:50 | #39 |
Участник
|
Цитата:
По мере обновления блокировки будут наоборот, накладываться. Это если будет использоваться оптимистическая модель блокировок При пессимистической в конечном счете, скорее всего, будет заблокирована вообще вся таблица (конечно, сильно зависит от распределения данных по компаниям)
__________________
Axapta v.3.0 sp5 kr2 |
|
24.01.2014, 10:15 | #40 |
Талантливый разгвоздяй
|
Цитата:
В таком случае, все записи сначала блокируются, затем система обновляет их все по порядку и в процессе обновления снимает блокировки следующим образом (оптимистичная модель):
Последний раз редактировалось Kabardian; 24.01.2014 в 10:23. |
|
Теги |
базовая информация, транзакции |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|