Re: [w3c/IndexedDB] Allow more explicit control over transaction lifetimes (#34)

asutherland left a comment (w3c/IndexedDB#34)

waitUntil feels like the most idiomatic option available right now which is also least likely to result in hung transactions since async functions are the norm and will reject on thrown errors propagating out, which can then reject the transaction.  Whereas manual calls to commit that are made in an async function will need manual error handling.  ([await using](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/await_using) is not yet available in webkit, so isn't currently an option.)

It's still possible for the transaction to hang, of course.  In 2019 I may have been pitching that we could leverage [the web-locks spec reserving dash-prefixed resource names for system use](https://w3c.github.io/web-locks/#resource-names) to magically expose IDB transactions into web-locks so they could be stolen.  I'm not sure of the utility of this complexity versus just specifying https://github.com/w3c/IndexedDB/issues/425 to create a time-based backstop which I imagine might be what any libraries would just end up implementing on their own too unless they try and do something clever with WeakRefs/WeakMaps.

My main concern at this point is primarily that we do need to maintain the concept of a transaction being forced to be inactive during structured cloning/key serialization even as we make it active otherwise most of the time.  (We could also just introduce a concept of the transaction being "busy" or something like that to cover that use-case.)

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

Message ID: <w3c/IndexedDB/issues/34/5456745134@github.com>