Re: [slightlyoff/ServiceWorker] Cache transactions & fixing `addAll` (#823)

>From the use-cases discussed, it seems like this is mainly about the deletion race.  What about just adding a deleteResponse(request, response) mechanism that only deletes what it finds at the request if it finds the same response still there?  (Compare-and-swap style.)  Depending on how cool people are with hidden state on Request instances, CacheQueryOptions could also be augmented to include a field "matchExistingRequest" so that delete(request, { matchExistingRequest: true }) could accomplish the same thing without requiring match() or matchAll() to be used to get the responses.  This could also be made the default for delete without options specified to eliminate the existing foot-gun nature of the idiom.

This allows deletion logic to operate asynchronously and only delete the things it thinks it's deleting.  From the deleting logic's perspective, its request will have been applied regardless of what writers get up to.

Meta-wise, the transactions seem too powerful[1]/complex and encroach on the domain of IndexedDB which is already capable of cleverly storing and returning Blobs.  The only deficiency for caching with IndexedDB is that writers block readers, but a "readlatest" transaction type could be added that presents readers with a coherent read-only view of the database as if any currently active/future active readwrite transactions did not exist.  (Gecko's SQLite WAL-based IndexedDB and Blob/File magic can support this, and my impression of Blink/Chromium's IDB is that it uses LevelDB whose snapshots could probably support this, although I have no idea how the blob/file impl works there so maybe not.)

1: Like, it seems to create a new cross-worker/document (a)synchronization/coordination primitive and could potentially encourage people to do data-dependent things in caches.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/823#issuecomment-203761075

Received on Thursday, 31 March 2016 05:41:50 UTC