-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Add explicit IDBTransaction.commit() (was: add "writeonly" mode) #234
Comments
The big use case for this is performance:
|
@aliams, @wanderview, @beidson - any initial feedback (not official opinions) on this idea? A non-starter, or something that would be worth the Chrome team prototyping? |
301 @asutherland |
FYI, I sketched out another idea a few years ago - adding an explicit |
It would of course be useful to have an idea that a commit() will be coming before the requests start getting issued. Perhaps commit() could be paired with something like At least in Gecko's implementation, this would allow us to greatly optimize against janking as long as no listeners were added to the requests. Obviously, if 100 requests are dispatched and each has a listener, dispatching all 100 in a single go just before the complete/abort happens is potentially much worse than the status quo. That said, beginBatch should still allow for implementation latitude so that the 100 can be spread out over multiple logical tasks/events to avoid dominating the event loop. |
Thanks @asutherland ! I'll pursue
|
Given that the main benefit here is performance, I agree If the core performance issue is that creating too many callbacks in the form of multiple |
Early draft PR added (#242) - any additional eyeballs on that would be welcome. |
Speculative Firefox/Gecko bug tracking implementing this is https://bugzilla.mozilla.org/show_bug.cgi?id=1497007 but we're not actually ready to implement at this time. |
As discussed in #234, an explicit commit() method is added to IDBTransaction which signals that no further requests can be made, which in turn allows implementations to initiate the commit process without additional round trips between script's event loop and the database task queue.
Merged PR the spec. I'm not assuming it's perfect, but let's iterate on the spec with additional bugs, so let's close this. Thanks to everyone for the discussion! |
As discussed in #234, an explicit commit() method is added to IDBTransaction which signals that no further requests can be made, which in turn allows implementations to initiate the commit process without additional round trips between script's event loop and the database task queue.
Forked off from #34 and previous mentioned on the old wiki, but formalizing it a bit:
put()
oradd()
will throwNotSupportedError
put()
andadd()
return null (return type changed toIDBRequest?
)success
/error
events not fired (i.e. don't bubble up to the transaction/connection)add()
) still causes the transaction to abortcomplete
/abort
events are still fired against the transactionThere is probably additional spec text required for clarity, but effectively since the transaction can no longer become active after the cleanup transactions steps run when the task ends, the transaction can attempt to commit immediately; it needs to wait until all of the
put()
s/add()
s finish. The transaction lifetime steps are still a bit wishy-washy; I didn't completely revise those as part of the big 2.0 rework of the spec.The text was updated successfully, but these errors were encountered: