_bobмоя позиция: параллельные процессы приведут к плачевным результатам, какой уровень изоляции не ставьЕсли писать код, не задумываясь о взаимодействиях и возможных блокировках (как это обычно и происходит), тогда да. Лично мне Ваш подход вполне себе понравился.

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

Одна точка зрения предпочитает вполне обоснованно обходить возможные трудно выявляемые проблемы с блокировками, а не бороться с ними. Эта точка зрения мне вполне понятна, когда нужно получить достаточно быстро результат, который не заведет в тупик.

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

По-моему, в принципе оба подхода имеют право на жизнь. ПМСМ, ваш спор - о предпочтениях.

Кстати, о параллелизме. Существует очень классная нотация именно для параллельных процессов - BPMN. Изначально она нацелена на распараллеливание именно бизнес -процессов, но по-моему, идеи, которые в нее заложены, позволяют на ее основе реализовать также визуальное программирование любых параллельных процессов. В такой нотации лично мне были бы совершенно не страшны блокировки и иные проблемы параллельной обработки - они очень красиво в ней разруливаются. Так что обобщать, ПМСМ, не стоит.

OremaxЯ бы разделял понятия бизнес-процесс и бизнес-операция, т.к. бизнес-процесс, как правило, состоит из нескольких бизнес-операций, которые выполняются в различных транзакциях.Бизнес-операция, на мой взгляд, это набор действий выполняемых в пределах одной транзакции. Конкурируют за свободные ресурсы именно бизнес-операции, например, при установке резерва конкурентным ресурсом является свободное количество товара. Поэтому мне не понятно, как BPMN поможет "разрулить" конкуренцию за ресурсы.В BPMN имеется собственное понятие "длинной транзакции" (или "бизнес-транзакции"). В отличие от "короткой" СУБД-шной транзакции такие транзакции, в соответствии с их концепцией, могут длиться месяцами. Однако, такие транзакции реализуются без взаимных блокировок. Каким образом? Таким, что нотация предполагает доступ к данным иных выполняющихся в данный момент экземпляров процесса. Из любого экземпляра процесса (транзакции) можно получить доступ к данным других экземплярам как этого же самого процесса, так и других процессов, определить, какие данные наиболее приоритетны в данный момент для каких процессов и "разрулить" конфликты доступа несколькими разными способами, которые на уровне СУБД выглядели бы как "низкоуровневые". В частности, откат "длинной транзакции" может быть осуществлен не "на полном автомате" возвратом всех данных в исходное состояние на момент "до транзакции", но и явно указанными действиями, которые могут корректировать и/или дополнять механизм отката по умолчанию. Обращение к данным может быть организовано с использованием механизма "событий" которые обрабатываются от многих совершенно разных процессов единообразно, если эти процессы обращаются к дефицитным ресурсам, например, с помощью "самодельных очередей", которые реализуются отдельными подпроцессами, к которым обращаются все остальные процессы, которым может потребоваться дефицитный ресурс. И тут уже только от фантазии и профессионализма разработчика зависит, как реализовать механизмы разруливания различных конфликтов. Важно, что эти механизмы открыты, их можно делать самим, оперируя не "таблицами", "строками", "индексами" и иными объектами концепции СУБД и "данностью" в виде правил ACID, а можно самому явно прописать механизмы блокировок при обращении к данным из разных процессов и с разными целями.
Кажется, что это делает разработку более низкоурвневой. С одной стороны это действительно так. С другой стороны, нотация BPMN имеет специальные средства для распараллеливания потоков данных и потоков управления, сбора "пучка потоков" в один поток, взаимодействия различных потоков между собой посредством сигналов или сообщений. Посредством этой нотации можно совмещать довольно сложные участки обработки данных, которые требуют отчасти строго-последовательной обработки, а местами допускают распараллеливание. Легко и просто делается "пообъектная" обработка, которую можно выполнить для коллекции объектов либо путем "последовательного перебора" объектов, либо созданием отдельного экземпляра процесса для каждого объекта, требующего обработки. Потому такая нотация, если ею заменяется "программирование вообще" может творить чудеса.
Все эти "мютексы", "сигналы", "сообщения", которые есть в операционной системе - это классно, но где они в языках высокого уровня? Их нет! Нужно писать код с использованием древнего "последовательного" алгоритмического подхода, а взаимодействие параллельных процессов рисовать где-то отдельно на бумажке или пытаться впихнуть в мозг до получения вывиха мозга. Удобных средств визаулизации параллельного программирования, параллельных алгоритмов - не было. Пока не появился BPMN. В нем реализованы революционные идеи. Разработчик, глядя на схему процессов, "проваливаясь" в детализацию схемы (детализируя, выполняя декомпозицию), либо выходя на верхний уровень, может одновременно наблюдать и удобно укладывать у себя в голове множество совершенно разных процессов, выполняющихся в разных ритмах, имеющих множество экземпляров каждый, но при этом взаимодействующих таким образом, что это взаимодействие не выносит мозг.

s_ustinovПо моему мнению, правильный подход при написании ERP системы - включить SERIALIZABLE и "писать код, не задумываясь о взаимодействиях и возможных блокировках". С точки зрения прикладного программиста СУБД сама обеспечит "ПОСЛЕДОВАТЕЛЬНОЕ выполнение транзакций в СУБД, независимо от того, как вы их выполняете на сервере приложений".Это не всегда срабатывает. Более того, такой подход может привести к дедлокам, если в транзакции Т1 производится блокирование ресурса Р1 с ожиданием освобождения ресурса Р2, а транзакция Т2 блокирует ресурс Р2 и ожидает освобождения ресурса Р1, заблокированного транзакцией Т1. Использования "правильных" уровней блокировок недостаточно - все равно приходится вникать в логику.

Кроме того, когда используется некий промежуточный язык, который сам формирует запросы к СУБД, например, язык 1С, при не совсем правильном использовании, может статься, проверка статуса будет выполнена в одном SQL запросе в первой транзакции, а модификация записи после проверки статуса - в другом запросе, во второй отдельной транзакции. И между этими транзакциями СУБД успеет изменить статус проверяемой записи за счет третьей транзакции, выполненной, к примеру, совсем другим пользователем.

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