| bc-version |
domain |
keywords |
technologies |
countries |
application-area |
|
|
performance |
| confirm |
| strmenu |
| dialog |
| transaction |
| lock |
| user-interaction |
|
|
|
|
Do not hold locks while waiting for the user
Description
A Confirm, StrMenu, modal page, or other user prompt issued from inside a write transaction stalls the transaction — and therefore every lock it holds — until the user responds. Per the upstream guidance, "Avoid user interactions (Confirm, StrMenu) inside transactions — they hold locks while waiting for user input." The wait is bounded only by the user; meanwhile other sessions block on whatever this transaction has acquired.
Best Practice
Sequence the operation so user confirmation happens before any database write that takes a lock the prompt holds open. The shape is: ask the user → if confirmed, acquire locks and post. if Confirm(...) then begin SalesHeader.LockTable(); SalesHeader.Get(DocNo); PostSalesOrder(SalesHeader); end; keeps the lock window down to the work itself.
See sample: avoid-user-prompts-inside-transactions.good.al.
Anti Pattern
SalesHeader.LockTable(); SalesHeader.Get(DocNo); if Confirm('Post this order?') then ...; — the lock is held for as long as the dialog is up. A user who steps away to lunch holds the lock for an hour, and every other session that touches that row blocks for the duration.
See sample: avoid-user-prompts-inside-transactions.bad.al.