Skip to content
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

Allow more explicit control over transaction lifetimes #34

Open
inexorabletash opened this issue Aug 10, 2015 · 3 comments

Comments

@inexorabletash
Copy link
Member

commented Aug 10, 2015

Imported from https://www.w3.org/Bugs/Public/show_bug.cgi?id=11528

Based on lots of developer feedback, in addition to the current automatic commit model it would be nice to support:

  • explicitly committing, to avoid extra round-trips (known performance bottleneck)
  • ways to defer committing to allow other async processing to occur within transaction scope

Both make the transaction model more complex, so we should tread carefully.

@inexorabletash

This comment has been minimized.

Copy link
Member Author

commented Aug 10, 2015

@inexorabletash inexorabletash referenced this issue Aug 10, 2015
14 of 14 tasks complete
@inexorabletash

This comment has been minimized.

Copy link
Member Author

commented Sep 28, 2015

In addition, for many puts, the overhead of all the individual success events can jank the main thread. We may want to design this in such a way that the transaction just opts-out of the per-request events entirely - possibly put() and friends just return null in those cases!

@inexorabletash

This comment has been minimized.

Copy link
Member Author

commented Sep 20, 2019

TPAC 2019 Web Apps breakout:

Looked at two proposals:

  • On IDBTransaction add waitUntil(promise). Can be called multiple times. Try redefine autocommit behavior in terms of these promises resolving (i.e. unify requests and promises).
  • On IDBDatabase.transaction() add an option manualCommit: true; commit() must be called explicitly.

Notes:

  • Expect most usage to be by wrappers/libraries.
  • Attendees were pretty split - explicit commit is more like traditional database APIs, promises build on SW/WebLocks patterns and reduce risk of coding deadlocks
  • Using either option puts the transaction into a new mode where new requests can be made at any time.
  • At first glance, seems like either option can be polyfilled on the other

Next steps: make concrete proposals; reach out to library authors to get feedback on preferences

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.