Interface IndexedDbCrossTabOptions

How tabs coordinate their saves.

interface IndexedDbCrossTabOptions {
    locks?: null | IndexedDbLockManager;
    rollbackRefusedSaves?: boolean;
}

Properties

locks?: null | IndexedDbLockManager

The lock manager: the browser's navigator.locks when left out. null coordinates by the version stamp alone, as the adapter does where the browser has no Web Locks.

rollbackRefusedSaves?: boolean

Gives up the writes of a save IndexedDB refused (a quota error, an aborted IndexedDB transaction) before the next coordinated call runs: the stored image is read back in place of the one in memory while the Web Lock is still held (without Web Locks, before this adapter's next coordinated call starts), so a statement queued behind the refused call neither reads its writes nor stores them, and the call still rejects. It covers every save made under the coordination: a statement's, a transaction's, an import's and close()'s. When IndexedDB cannot be read back either, no save stores the refused writes, and the next statement or transaction reads the stored image before it runs, failing while it cannot.

Off by default: the refused writes stay in memory, and the next coordinated statement, a read included, stores them with its own. A caller's reload() in its catch runs after the statements already waiting on the lock, so it cannot take them back first.