/object-locks

name: object-locks
description: "Объектные блокировки 1С — пессимистическая и оптимистическая. Используй когда нужно защитить объект от конкурентного редактирования, разобрать «Запись была изменена или удалена другим пользователем», «объект заблокирован», выбрать между Заблокировать и ЗаблокироватьДанныеДляРедактирования, решить про идентификатор формы или обработать конфликт версий."

Object Locks: Pessimistic And Optimistic

MCP routing

• Preferred path: use MCP `unica` tools `unica.view {}`, `unica.search`, `unica.apply`, `unica.view` on the form node, `unica.check`, and `unica.run`.
• Runtime идёт через `unica.run`: вызов без `op` отдаёт словарь операций и

контракт каждой — `argsSchema`, `execution`, `previewRequired`, `dryRunRequired`. Контракт вызова бери оттуда, а не из этого текста; при `implemented: true` используй опубликованную `argsSchema`; при `support.state: limited` разрешено только подмножество `support.supportedArgs`. При `support.state: unavailable` остановись; не выдумывай аргументов при `argsSchema: null`. Для плановой операции сначала проверь результат `dryRun: true`, затем исполняй запрос с `dryRun: false`. Preview не фиксирует входы между вызовами. Не обходи контракт прямым runner-ом.

• Use `unica.docs` with `source: "development-standard"` for the one development-standard here, 490, and for related ones 648 and 783. These are standards, not evidence of runtime behavior; confirm the wording before citing one.
• Reproducing a conflict requires separate runtime evidence; a `unica.run` preview or a `unica.check` verdict does not infer it.
• Do not call internal analyzer, runtime, standards, or package adapters directly. They are hidden behind MCP `unica`.

Scope boundary

This skill owns concurrency between **users editing the same object**. Concurrency between transactions contending for data — managed locks, responsible reading, transaction shape — belongs to `transactions-locks`. The two mechanisms have different lifetimes and different failure modes, and one is not a substitute for the other.

References

• Read `../../references/platform/object-locks.md` for both lock kinds, lock lifetime, the form id rule, and how object locks interact with transactions.
• Read `../../references/platform/transactions-locks.md` when the same code path also reads data that drives a write.
• Read `../../references/platform/form-events.md` when the editing path runs through a non-standard form module.

Core model

Two locks doing two different jobs:

• **Pessimistic** stops the object being *edited* elsewhere while someone holds it. Set around editing, released when the form closes or the session ends.
• **Optimistic** stops a *write* whose in-memory object is stale. A version check performed at write time, always on, not configurable per write.

Two facts decide most reviews:

• **The pessimistic lock is cooperative.** It does not prevent the object in the database from being modified or deleted — it only prevents another lock on the same data. The object is protected only because every modifying path locks first. One path that writes without locking makes the scheme decorative, which is why std490 requires taking the lock before modifying an existing object from code.
• **Optimistic locking guarantees only non-overwriting.** A stale write is refused, including one from another software object in the same session. Nothing is merged, and the user is not told what changed.

Workflow

1. Name the concurrency you are actually facing: two users on one object → this skill; two transactions on shared data → `transactions-locks`. 2. Find every path that modifies the object: `unica.view` at `<method>.Caller` lists the callers of a writing method, and `unica.search` by the method and object names finds literal mentions. A cooperative lock is only as good as the path that skips it. 3. Choose the shape before writing code: fail loudly so the user learns who holds the object, or skip and retry on the next run for background work (std490). 4. Decide the form id question. With a form id the lock follows the form's lifetime; without one it follows the session, the server call, or the transaction. Do not mix both for the same object — that combination raises. 5. Inspect a non-standard editing form with `unica.view` on the form node and reproduce the standard behaviour with the form lock and unlock methods. 6. Decide what the version conflict says to the user before it happens; the platform's own message names nothing useful. 7. Apply with `unica.apply` (`code.replace` or `code.insert`), verify statically with `unica.check`; require separate two-session evidence before calling the conflict reproduced.

Design rules

• Take the object lock before modifying an existing object from code (std490), through the object's `Заблокировать()` or the global `ЗаблокироватьДанныеДляРедактирования()`.
• Background and scheduled work catches the lock failure, logs a warning to the event log, skips the object, and picks it up next run. Blocking a user from a job is not an option.
• Object locking operations affect only other object locking operations — not data operations and not the transaction flow.
• A failed object lock inside a transaction does **not** require rolling that transaction back. It may be caught and the transaction continued; this is the qualifier on the general rollback reflex in `transactions-locks`.
• A lock taken inside a transaction without a form id is released when the transaction ends.
• A version conflict is reported to the user in application terms, not as a raw platform message.

Review checklist

• Every path that modifies the object takes the lock, including the ones reached from jobs and integrations.
• The chosen shape matches the caller: loud for interactive, skip-and-log for background.
• Locking with and without a form id is not mixed for the same object.
• Locks taken from code are released, or their release is explained by the lifetime chosen.
• No