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

> I'm hoping squashing can always turn interleaved puts and deletes into a series of puts, then deletes. If all the puts succeed, then you're just left with the deletes… what could cause a delete to fail?

I think this depends on if we allow put(), match(), delete() within a transaction.  If you can interleave reads and writes, then you cannot safely reorder writes.

Also keep in mind we have the rules about match()+delete() leaving the Response returned from the match() as a functioning object.  Any body file storage needs to exist until the Response is gc'd.  How does this work with a match() within a transaction?  Are Response and Request objects normally kept alive past the end of the transaction?  What about a Response from a rejected/rolled-back transaction?

I think I can accommodate keeping those Response objects alive in the gecko impl because I keep the body in a separate file from the sqlite database.  I just need to track when the last use of any particulr body file goes away and reap the file at that point.  That may not be the case for all implementations, though.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/823#issuecomment-174244113