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.
The text was updated successfully, but these errors were encountered:
If the demo page crashes or is closed during a transaction on the IndexedDB VFS, e.g. if the user executes a
BEGIN TRANSACTIONand no subsequentCOMMITorROLLBACK, then the database will have an orphaned lock and all future locking attempts will fail withSQLITE_BUSY.If the journal is not also written to IndexedDB (e.g.
PRAGMA journal_mode = MEMORYorOFF) 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 resettingisLockedin 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.
The text was updated successfully, but these errors were encountered: