Как абапер, отвечу:
Вестниксистемный уровень: выделенный менеджер блокировок - это зло на современном этапе развития субд, которые вполне себе адекватно научились работать с блокировками.
Блокировки уровня СУБД не подходят по разным причинам, вот некоторые из них:
1. Саповская блокировка устанавливается на некий логический объект (документ, заказ), который может жить в десятке таблиц
2. Саповская транзакция (SAP LUW, в терминах сапы) может содержать в себе больше одной транзакции БД. Живут ли блокировки уровня БД за пределами одной транзакции БД?
3. В процессе работы саповская программа может выполняться сначала одним процессом сервера приложений, потом другим, потом снова первым. Как между такими процессами (разными с точки зрения СУБД) сохранять блокировку обрабатываемых данных?

А так как серверов приложений может быть много - поэтому и есть выделенный менеджер блокировок, который все это разруливает

Вестникэто плохо масштабируется, это плохо кластеризуется.
Не могу судить однозначно, но неплохо жило и живет. По крайней мере с сервером блокировок в качестве узкого места сталкиваться пока не приходилось.

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

Вестникв самом худшем случае это выглядит так:
* вы создаете объект
* он получает номер
* вы делаете commit work
* что-то прописывается в буфера и вам возвращается управление. никакого коммита в базу пока еще нет!!!
* изменения БЛОБом записываются в таблицу vbdata
* отдельный процесс из vbdata распихивает данные по нужным табличкам
Это не худший случай, это совершенно нормальный, точнее один из. А еще точнее - вы описали асинхронное обновление, есть еще и привычное синхронное - когда после commit'а изменения сразу попадают в БД. Мне бы не хотелось углубляться в объяснение архитектуры сапы и почему был придуман именно такой алгоритм, но вообще способ сохранения данных в БД зависит от конкретной задачи

Вестник* только теперь ваш процесс может работать дальше, будучи уверенным, что все остальные вызываемые им же (в том же потоке!) ФМ-ы увидят его изменения. и никакого способа узнать, когда же наступит этот счастливый момент
При вышеописанном вами асинхронном обновлении - действительно нет простого способа узнать когда оно закончилось, на то оно и асинхронное. Но если вам нужно получить результат выполнения - значит нужно обновлять синхронно, что делается весьма просто. Куски кода нужны или поверите на слово?

Вестникабаперы в большинстве своем люди задавленные консалтинговым прессом, поэтому не мудрствуя лукаво делают цикл ожидания... со всеми вытекающими
Быдлокод есть везде. А абаперы, которые делают цикл для ожидания обновления БД - именно быдлокодеры


А по теме топика - понятия не имею, что лучше - OEBS или SAP :) но с точки зрения специалиста, который работает по найму - количество вакансий на ХХ говорит само за себя.

ВестникНо если вам нужно получить результат выполнения - значит нужно обновлять синхронно, что делается весьма простоэто не я, это стандартные бапи так работают. мне нужно как-то дождаться окончания...

Куски кода нужны или поверите на слово?если это вас не сильно затруднит
Пожалуйста...

В этом случае модули обновления выполняются не в отдельном update-процессе, а в текущем. И соответственно управление в программу вернется только после того как отработают все обновления


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

Вестникскажите пож-ста, у вас внедрен replicated enq? или вы полностью поднимаете инстанс при failover? (это ведь лучшая практика, не так ли?)
Понятия не имею, если честно. Я не базисник, мне достаточно того что это работает и не спотыкается. Как программисту мне приходится сталкиваться с вопросами производительности - это бывают кривые программы, либо проблемы с серверами приложений или БД - но с проблемами производительности или косяков сервера блокировок встречаться не приходилось.

Вестникесли бы все было так просто... это первое, что мы сделали. это не работает
Ну что я могу тут сказать... у нас работает. Значит надо разбираться, глядеть код, садиться с отладчиком и т.д.

bahrovArmann7Мне бы не хотелось углубляться в объяснение архитектуры сапы и почему был придуман именно такой алгоритм, но вообще способ сохранения данных в БД зависит от конкретной задачи Очень интересно для какой задачи такого асинхронного монстра придумали?
iscrafm вам правильно ответил.

Кроме того, из менее глобального:
- если пользователю не нужен введенный документ 'прямщас', то нет смысла заставлять его ожидать пока все обновится - пусть дальше работает
- что бы сделать транзакции БД короткими по времени. Многие саповские программы построены по принципу визардов, когда вы работаете с последовательностью экранов - заполняете один диалоговый экран, на нем отрабатывает какая либо логика, затем заполняете следующий экран, и т.д. Если на первом экране откроется транзакция в БД, коммит или откат произойдет на последнем экране, а пользователь между вторым и третим диалоговым экраном сходит пообедать или перекурить - то много таких открытых транзакций пойдут не на пользу производительности СУБД. А так всех обновления накапливаются, и пойдут в дело только при коммите
Есть еще причины, но мне бы не хотелось пересказывать трехдневный учебный курс по обновлениям БД для Сапа :)

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

Вестник, похоже вы точно знаете все недостатки и грядущую судьбу SAP ERP; я даже завидую. Чтож, успехов вам :)