Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to clear an orphaned lock on IndexedDB VFS #2

Closed
rhashimoto opened this issue May 2, 2021 · 1 comment
Closed

Add a way to clear an orphaned lock on IndexedDB VFS #2

rhashimoto opened this issue May 2, 2021 · 1 comment
Labels
bug

Comments

@rhashimoto
Copy link
Owner

@rhashimoto rhashimoto commented May 2, 2021

If the demo page crashes or is closed during a transaction on the IndexedDB VFS, e.g. if the user executes a BEGIN TRANSACTION and no subsequent COMMIT or ROLLBACK, then the database will have an orphaned lock and all future locking attempts will fail with SQLITE_BUSY.

If the journal is not also written to IndexedDB (e.g. PRAGMA journal_mode = MEMORY or OFF) then the database may be unrecoverably corrupted and it should be deleted (but see below). If the journal is on IndexedDB then forcibly clearing the lock (by resetting isLocked in the metadata object) will allow the database to be automatically repaired if necessary on the next usage.

These operations can be done directly on the IndexedDB store, but there should be methods on the IndexedDB VFS for both.

As an aside, the database can be corrupted when the journal is lost because transaction changes are only partially written. With the current implementation this will happen when the maximum number of cached blocks is reached and subsequent writes cause dirty blocks to be incrementally flushed. If the VFS did not cap the number of cached blocks, they would all be written atomically upon sync and the database would never be left in a corrupted state even with no journal. The downside of that is unlimited memory usage for large transactions, but it's a trade-off worth considering for many (probably most) applications.

@rhashimoto rhashimoto added the bug label May 2, 2021
@rhashimoto
Copy link
Owner Author

@rhashimoto rhashimoto commented May 3, 2021

See 1c2b993 for use in the demo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug
Projects
None yet
Development

No branches or pull requests

1 participant