Как синхронизировать параллельные изменения и отделять регистрацию обновления от фиксации и фактического результата.
3 мин чтения·База знаний
Ревизия 1Применимость к указанным контекстамЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Параллельные изменения требуют контроля одновременно на уровне бизнес-объекта и на уровне записи в базе. В ABAP SAP LUW может включать несколько database LUW. Enqueue-блокировка может сохраняться между короткими database LUW, а обновление, зарегистрированное через Update Task, выполняется при фиксации SAP LUW. Поэтому «блокировка получена», «обновление зарегистрировано» и «изменение успешно сохранено» являются разными состояниями.
Lock object в ABAP Dictionary задаёт объект блокировки. При активации генерируются функции установки и снятия блокировки. До изменения прочитайте объект и получите нужную блокировку; при конфликте сообщите, что объект занят, или предложите безопасное перечитывание. Не продолжайте запись на основании устаревших данных.
Согласуйте ключ блокировки с единицей бизнес-изменения. Если разные программы блокируют один документ по разным ключам или в разном порядке, защита становится неполной и может привести к взаимному ожиданию. Блокировку держите только пока она необходима, и завершайте её при штатном исходе, отмене или ошибке в соответствии с транзакционной моделью приложения.
Enqueue-блокировка управляется SAP lock service и отличается от кратковременной database lock. Она позволяет синхронизировать доступ через несколько database LUW, но не заменяет проектирование ключа, прав доступа или проверки инвариантов. Проверьте режим и время жизни блокировки в документации конкретного приложения; поведение обычных транзакций нельзя автоматически приравнивать к RAP locking и draft lifecycle.
CALL FUNCTION ... IN UPDATE TASK регистрирует update function module и параметры для более позднего выполнения. Сам вызов не исполняет функцию. COMMIT WORK запускает зарегистрированные обновления. ROLLBACK WORK до фиксации отменяет регистрацию текущей SAP LUW.
Обычный COMMIT WORK не ждёт результата асинхронного update process. Поэтому успешное завершение диалоговой программы не всегда означает, что все последующие изменения обновления успешно применены. COMMIT WORK AND WAIT ждёт завершения синхронного обновления высокого приоритета V1 и позволяет программе обработать его результат. Это не делает внешние вызовы, побочные эффекты или отдельные процессы частью одной атомарной транзакции.
Учитывайте ограничения update function module: нельзя выполнять внутри него собственный COMMIT WORK или ROLLBACK WORK, а разрешения пользователя нельзя считать проверенными там автоматически. Проверяйте полномочия и корректность параметров до регистрации обновления, а ошибки и повторную обработку согласуйте с владельцем процесса. Для диагностики асинхронных ошибок используйте предусмотренный мониторинг обновлений; не запускайте повторно запись вслепую.
До реализации запишите: объект и ключ блокировки; когда блокировка берётся и снимается; какие проверки выполняются до записи; какие изменения идут в диалоге, а какие через update task; точку COMMIT и смысл ответа пользователю; поведение при конфликте, отмене и ошибке update; способ сверить созданный документ.
После разрыва связи между клиентом и сервером сначала выясните состояние операции по бизнес-ключу или идентификатору корреляции. Повторный запрос без такой проверки способен создать дубликат, если исходная фиксация прошла, а ответ потерялся. Проектируйте идемпотентность и сверку отдельно от enqueue lock: блокировка предотвращает одновременное изменение, но сама по себе не дедуплицирует повторные запросы.
Проверяйте минимум два конкурирующих изменения одного объекта, отказ в получении блокировки, rollback до commit, сбой синхронного обновления, ошибку асинхронного V1/V2 сценария и повтор запроса после неопределённого сетевого ответа. Сверяйте статус бизнес-объекта, документ и итоговые суммы, а не только возврат управления из вызывающей программы.
Ссылки описывают ABAP Platform и SAP Application Server для указанных выпусков. Детали блокировки и обновления зависят от стека и используемого фреймворка. В этом проекте нет SAP runtime; конкурентные транзакции и Update Task не выполнялись.
Concurrent changes require control at both the business-object level and the database-record level. An ABAP SAP LUW can include several database LUWs. An enqueue lock can remain set across short database LUWs, while an update registered through Update Task executes when the SAP LUW is committed. Therefore, 'lock acquired', 'update registered', and 'change saved successfully' are different states.
A lock object in the ABAP Dictionary defines a lockable object. On activation, lock and unlock function modules are generated. Read the object and acquire the required lock before changing it; on collision, report that it is busy or offer a safe reread. Do not continue writing based on stale data.
Align the lock key with the unit of business change. If programs lock the same document with different keys or in different orders, protection is incomplete and can lead to deadlocks. Hold a lock only as long as necessary, and release it on success, cancellation, or error according to the application's transaction model.
An enqueue lock is managed by the SAP lock service and differs from a short-lived database lock. It can synchronize access across several database LUWs, but does not replace key design, authorization, or invariant checks. Verify lock mode and lifetime in the documentation for the specific application; do not assume that ordinary transactions and RAP locking or draft lifecycles behave identically.
CALL FUNCTION ... IN UPDATE TASK registers an update function module and its parameters for later execution. The call itself does not execute the function. COMMIT WORK starts registered updates. ROLLBACK WORK before commit cancels registrations for the current SAP LUW.
A regular COMMIT WORK does not wait for the asynchronous update process. Successful completion of the dialog program therefore does not always mean that all later update changes were applied successfully. COMMIT WORK AND WAIT waits for synchronous high-priority V1 update completion and lets the program handle its result. This does not make external calls, side effects, or separate processes part of the same atomic transaction.
Account for update-function restrictions: an update function module cannot perform its own COMMIT WORK or ROLLBACK WORK, and user authorization must not be assumed to have been checked there automatically. Check authorization and parameter validity before registering the update, and agree on error and reprocessing behavior with the process owner. Use the provided update monitoring for asynchronous errors; do not blindly repeat a write.
Before implementation, record the object and lock key; when the lock is acquired and released; checks before writing; which changes run in dialog and which through update task; the COMMIT point and meaning of the user response; behavior on collision, cancellation, and update error; and how to reconcile the created document.
After a client-server connection drops, first determine the operation state using a business key or correlation ID. Repeating a request without that check can create a duplicate if the original commit succeeded but its response was lost. Design idempotency and reconciliation separately from enqueue locking: a lock prevents concurrent modification but does not deduplicate repeated requests.
At minimum, check two concurrent changes to one object, a lock collision, rollback before commit, synchronous update failure, asynchronous V1/V2 error handling, and a retry after an uncertain network response. Reconcile the business-object status, document, and totals rather than checking only that the calling program returned.
The links describe ABAP Platform and SAP Application Server for the cited releases. Lock and update details depend on the stack and framework. This project has no SAP runtime; concurrent transactions and Update Task were not executed.