Skip to content

The steps for opening a database are racy #81

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

Closed
nox opened this issue Jul 12, 2016 · 2 comments
Closed

The steps for opening a database are racy #81

nox opened this issue Jul 12, 2016 · 2 comments
Labels

Comments

@nox
Copy link
Contributor

nox commented Jul 12, 2016

If two separate event loops in the same origin queue a task for opening a database that didn't exist before in step 3 of IDBFactory.open at the same moment, can't step 4 (If db is null, let db be a new database with name name, version 0 (zero), and with no object stores) of the former algorithm create two databases with the same name in the same origin? Shouldn't the spec have prose to prevent that race condition?

Cc @bakulf

@inexorabletash
Copy link
Member

Yes, this is related to #78 and #79 - the queue that open (and delete) requests are made against is not an event loop, but an abstract queue of open/delete requests associated with an (origin, name) tuple.

inexorabletash added a commit that referenced this issue Jul 15, 2016
Also:
* Remove 'delete pending' flag which is not longer needed.
* Simplify some section names.
* Move the versionchange/blocked logic from upgrade steps to
  open steps, for symmetry with delete steps.
* Rename 'Authorization' section to 'Security Concerns'
@inexorabletash
Copy link
Member

Should be resolved by d1147cb - take a peek?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants