Re: [w3c/IndexedDB] Disallow starting readwrite transactions while readonly transactions are running? (#253)

I guess I'm picturing 2 primary use-cases:
1. Something like LRU eviction that operates on streaming processing of the current contents of the database where the reads use cursors/similar to perform mutations in bite-sized pieces.  This could be a fairly large amount of data and take a fairly long time.
2. Complicated upgrade scenarios that may require IndexedDB enhancements.

### Complicated Upgrade Scenarios ###
I think the idealized upgrade scenario for ServiceWorkers as naturally flows from the spec is that the SW script is changed whenever an upgrade needs to happen and it populates a new CacheStorage cache asynchronously during a waitUntil()'ed "install".  Normal activation happens or a complicated dance with skipWaiting()/claim() happens.  The newly activated ServiceWorker serves out of the new cache.

In practice, it seems like many ServiceWorker authors do not want to change the ServiceWorker script when they make changes to their app.  Instead, they want the ServiceWorker to be parameterized.  This can work with the above, but one problem is that if the cache name/IDB name isn't something hardcoded into the SW script that gets updated, a mechanism like https://github.com/w3c/ServiceWorker/issues/1331 that's synchronously available is desired so the right cache/db can be opened.  Or there needs to be a way to pivot the new cache/database to replace the old database.

Pivoting from old to new storage could happen in a few ways:
- Atomically renaming caches / IDB databases.  This is not yet a thing.
- Use a lock or transaction to stall new requests while the new, already-fetched state is propagated into the "current" database.  The IDB transaction model doesn't quite work here without jumping through some hoops to spam the target "readwrite" database with no-op requests if the source isn't delivering data fast enough.  This could all be made less ugly if IDB started supporting waitUntil()/web-locks, but then things could end up blocking for quite some time.  So then a snapshot mechanism potentially looks more attractive, especially because it could also simplify the update process.
- Something involving storage buckets.  Be able to clone/fork them and/or rename them.
- Addressing https://github.com/w3c/ServiceWorker/issues/1331 with some means of having a per-ServiceWorker or per-registration store that has very good performance characteristics (synchronous or guaranteed <10ms fast async) so that people use it to identify the current db/cache names.

Tying this back to the issue, I think it would be good to have a general consensus about what directions we expect to move the IndexedDB spec to support storing Requests/Responses, and how large or over-engineered sites will deal with the upgrade mechanism.  I personally like the idea of having SW's create custom rename-able storage buckets that we are able to tie to their registrations (which helps with automatic cleanup), and giving them the option to fork existing storage buckets as a starting point.  Clever IDB/Cache implementations could use snapshot/copy-on-write/unionfs/refcounting/whatever mechanisms under the hood, whereas naive implementations could just brute force copy the data across.  And we'd never need to expose snapshot semantics to IDB.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/253#issuecomment-458345785