Class LockManager

Namespace

CSharpToJavaScript.APIs.JS

Assembly

CSharpToJavaScript.dll

The LockManager interface of the Web Locks API provides methods for requesting a new 'Lock' object and querying for an existing Lock object. To get an instance of LockManager, call 'navigator.Locks'.

[Value("LockManager")]
public class LockManager

Inheritance

object

LockManager

Inherited Members

object.GetType()

object.MemberwiseClone()

object.ToString()

object.Equals(object)

object.Equals(object, object)

object.ReferenceEquals(object, object)

object.GetHashCode()

Remarks

See also on MDN

Constructors

LockManager()

public LockManager()

Methods

Query()

The query() method of the LockManager interface returns a {{jsxref('Promise')}} that resolves with an object containing information about held and pending locks.

[Value("query")]
public Task<LockManagerSnapshot> Query()

Returns

Task<LockManagerSnapshot>

A {{jsxref('Promise')}} that resolves with an object containing a snapshot of the LockManager state.
The object has the following properties:The LockInfo object can have the following properties:

Remarks

See also on MDN

Request(string, LockGrantedCallback)

The request() method of the LockManager interface requests a 'Lock' object with parameters specifying its name and characteristics.
The requested Lock is passed to a callback, while the function itself returns a 'Promise' that resolves (or rejects) with the result of the callback after the lock is released, or rejects if the request is aborted.

[Value("request")]
public Task<dynamic> Request(string name, LockGrantedCallback callback)

Parameters

name string

callback LockGrantedCallback

Returns

Task<dynamic>

A 'Promise' that resolves (or rejects) with the result of the callback after the lock is released, or rejects if the request is aborted.

Remarks

The mode property of the options parameter may be either "exclusive" or "shared".

Request an "exclusive" lock when it should only be held by one code instance at a time.
This applies to code in both tabs and workers. Use this to represent mutually exclusive access to a resource.
When an "exclusive" lock for a given name is held, no other lock with the same name can be held.

Request a "shared" lock when multiple instances of the code can share access to a resource.
When a "shared" lock for a given name is held, other "shared" locks for the same name can be granted, but no "exclusive" locks with that name can be held or granted.

This shared/exclusive lock pattern is common in database transaction architecture, for example to allow multiple simultaneous readers (each requests a "shared" lock) but only one writer (a single "exclusive" lock).
This is known as the readers-writer pattern.
In the IndexedDB API, this is exposed as "readonly" and "readwrite" transactions which have the same semantics.

See also on MDN

Request(string, LockOptions, LockGrantedCallback)

The request() method of the LockManager interface requests a 'Lock' object with parameters specifying its name and characteristics.
The requested Lock is passed to a callback, while the function itself returns a 'Promise' that resolves (or rejects) with the result of the callback after the lock is released, or rejects if the request is aborted.

[Value("request")]
public Task<dynamic> Request(string name, LockOptions options, LockGrantedCallback callback)

Parameters

name string

options LockOptions

callback LockGrantedCallback

Returns

Task<dynamic>

A 'Promise' that resolves (or rejects) with the result of the callback after the lock is released, or rejects if the request is aborted.

Remarks

The mode property of the options parameter may be either "exclusive" or "shared".

Request an "exclusive" lock when it should only be held by one code instance at a time.
This applies to code in both tabs and workers. Use this to represent mutually exclusive access to a resource.
When an "exclusive" lock for a given name is held, no other lock with the same name can be held.

Request a "shared" lock when multiple instances of the code can share access to a resource.
When a "shared" lock for a given name is held, other "shared" locks for the same name can be granted, but no "exclusive" locks with that name can be held or granted.

This shared/exclusive lock pattern is common in database transaction architecture, for example to allow multiple simultaneous readers (each requests a "shared" lock) but only one writer (a single "exclusive" lock).
This is known as the readers-writer pattern.
In the IndexedDB API, this is exposed as "readonly" and "readwrite" transactions which have the same semantics.

See also on MDN