client.remote_lock.RemoteLock

The remote interface for a server-side Lock.

State model

The state properties (locked, locked_since, locking_user, locking_client, locked_by_us, remaining_lock_time_ms) are a local cache fed by an OPC UA data-change subscription. They are only eventually consistent with the server:

• They can lag by up to one publishing interval, including right after init_lock, break_lock, exit_lock or renew_lock returns.
• Nodes are notified separately, so values may briefly disagree with each other.
• A notification queued before a read_state call can arrive after it and briefly revert a field.
• remaining_lock_time_ms is the last reported value and is not counted down locally.

Intended use

Use the cache for displaying status and reacting to changes made by others. A successful init_lock or break_lock means we hold the lock; there is no need to wait for locked_by_us. The server enforces lock ownership, so a stale cache can at worst cause a rejected call, never an unauthorized one.

Use read_state when the exact state is needed. It reads all nodes in one request, returns an immutable consistent snapshot and by default updates the cache.

Signals

locked_changed and locking_user_changed fire only when the cached value changes, from any source, and can occasionally flicker. renew_due fires while we hold the lock and the remaining time is below renew_threshold (a fraction of the maximum), at most every renew_retry_seconds. A spurious renew_due is harmless.