4.11
Механизмов блокирования в современных СУРБД обычно недостаточно для обработки объектов коммерческих данных (таких, как заказы клиента), которые влияют на несколько таблиц базы данных. Для координации нескольких приложений, одновременно обрабатывающих один и тот же бизнес-объект, система R/3 предоставляет свое собственное управление блокировками, контролируемыми рабочим процессом обработки очередей.
Чтобы в системе могли выполниться запросы на блокировку необходимо сначала определить в ABAP-словаре объект блокирования. Объект блокирования содержит таблицы, записи которых должны быть заблокированы. Объект блокирования состоит из первичной таблицы. С помощью отношений по внешнему ключу можно также определить дополнительные вторичные таблицы (имя определяемого пользователем объекта блокирования должно начинаться с "EY" или с "EZ").
Для объекта блокирования можно указать режим блокирования ("S" - совместная блокировка или "E" - монопольная блокировка). Монопольную блокировку (режим "E") можно установить только в том случае, если никакой другой пользователь уже не установил блокировку для записи данных. Этот же пользователь может запросить дополнительную блокировку "E" или "S" в последовательности вызовов программ.
Если объект блокирования активирован, система генерирует функциональные модули ENQUEUE и DEQUEUE. Эти функциональные модули называются ENQUEUE_<имя объекта> и DEQUEUE_<имя объекта> и используются в АВАР-кодировке для блокирования и разблокирования данных.
4.12
При запросе на блокировку в системе выполняется проверка, не противоречит ли запрошенная блокировка существующим записям в таблице блокировок. При обнаружении такой ситуации запрос на блокировку отклоняется. После чего прикладная программа информирует пользователя о том, что в настоящий момент операция не может быть выполнена. Например, будет выведено сообщение "Данные в настоящее время используются. Изменение не возможно".
Управление блокировками (постановкой в очередь) осуществляется рабочим процессом обработки очередей, использующем таблицу блокировок. Таблица блокировок храниться в оперативной памяти сервера, на котором выполняется РП обработки очередей. Если диалоговый рабочий процесс и рабочий процесс обработки очередей выполняются на разных серверах, связь между ними осуществляется через сервер сообщений.
Блокировки, установленные прикладной программой, сбрасываются либо самой прикладной программой, либо специальной программой обновления (во второй части SAP-LUW; см. слайд, представленный ниже).
4.13
Транзакция соответствует логической единице обработки (LUW).
В связи с тем, что существующие системы баз данных не поддерживают выполнение транзакций, общих для всех процессов, необходимо различать элементарные шаги обработки (LUW) в системе R/3 и эти же шаги в системе базы данных (SAP-LUW/DB-LUW). DB-LUW либо полностью выполняется, либо обновление данных не происходит (выполняется откат). DB - LUW перемещает базу данных из одного согласованного состояния в другое. Это означает, что данные должны быть логическими и корректными, как до, так и поле LUW; это справедливо, как для DB - LUW, так и SAP - LUW.
Начало SAP-транзакции является также и началом SAP-LUW. Логические единицы обработки (SAP-LUW) завершаются выполнением ABAP-оператора "COMMIT WORK" либо завершением соответствующего асинхронного обновления (вторая часть SAP-LUW). Как было описано выше, каждый шаг диалога в SAP-LUW обрабатывается одним рабочим процессом, как и в случае с DB-LUW. Каждое изменение в базе данных выполняется в своем собственном DB-LUW.
Асинхронное обновление, обычно используемое в SAP - LUW, позволяет системе временно накопить изменения, выполненные пользователем, а затем при завершении фазы диалога (во второй части SAP - LUW) внести изменения в базу данных посредством отдельного рабочего процесса обновления. Для обеспечения непротиворечивости данных итоговое изменение базы данных (включающее в себя каждое "изменение шага диалога") выполняется только в одном заключительном DB - LUW.
|
