Object Locks

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, ifRevRequiredOnApply. Контракт вызова бери оттуда, а не из этого текста; выбирай только операцию с implemented: true и не выдумывай аргументов записи с argsSchema: null; превью исполнением не является. Не обходи контракт прямым 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 with unica.search by the method and object names; a call graph is not on the v0.13 surface. 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 transaction is rolled back merely because an object lock failed.
• The version-conflict path exists and says something actionable.
• A non-standard editing form sets and removes the lock the way the standard form extension would.

Stop rules

• Do not treat a pessimistic lock as protection against writing.
• Do not add an object lock in place of a managed lock on a read that drives a write; that is transactions-locks.
• Do not leave a version conflict surfacing as a raw platform error.
• Do not claim a concurrency fix without reproducing the conflict on two sessions.

Contract gaps

If public MCP unica cannot inspect the editing path, the form, or the runtime evidence needed to reproduce the conflict, report a Unica MCP contract gap with the missing operation.