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

Blocking Calls on versionTransactions #2

Open
axemclion opened this Issue Jun 11, 2012 · 3 comments

Comments

2 participants
@axemclion
Owner

axemclion commented Jun 11, 2012

Version transactions are not blocking, they should not allow any other transactions when version transactions are in progress

@ghost ghost assigned axemclion Jun 11, 2012

@brettz9 brettz9 added this to the 3.0.0 milestone Oct 18, 2016

@brettz9

This comment has been minimized.

Show comment
Hide comment
@brettz9

brettz9 Jan 20, 2017

Collaborator

Will really need to be handled along with #273 .

Collaborator

brettz9 commented Jan 20, 2017

Will really need to be handled along with #273 .

@brettz9 brettz9 self-assigned this Jan 20, 2017

@brettz9 brettz9 added this to TODO in Blocking Apr 2, 2017

brettz9 added a commit to brettz9/IndexedDBShim that referenced this issue Apr 14, 2017

- Breaking change to `__forceClose`: Prepend an optional argument to the
    signature, `dbName` for force-closing databases of a particular name
- Add missing API: `versionchange` and `blocked` events (currently assumes
    single process); addresses axemclion#2
- Fix: Close connection on abort (setting closed flag)
- Fix: Have `deleteDatabase` empty relevant `connections` (relevant
    for `__forceClose` as well as `open`)
- Refactoring: Rename `transformW3CStack.js` to `transformV8Stack.js`
- Refactoring: Move excluded files into good-bad files file
- Testing (W3C Old): Partly update `TransactionBehavior.js` tests to
    ensure `objectStoreNames` are compared as arrays
- Testing (Mocha): For now, make exception for Chrome as with other
    browsers to `window.onerror` tests in `IDBTransaction/events-spec.js`
    but keep note in testing list
- Testing (mock): Fix for `blocked` event's expected `newVersion` (submitted
    fix as <kristofdegrave/indexedDBmock#2>)

IndexedDB Test counts:
    323 normal files (including 1 domstringlist file):
        315 are all good, 3 have some that are bad,
        5 have some that time out and 3 have some that do not run
    7 excluded files (uncaught exceptions during testing):
        `bindings-inject-key.js`,
        `keypath-exceptions.js`,
        'event-dispatch-active-flag.js',
        'fire-error-event-exception.js',
        'fire-success-event-exception.js',
        'fire-upgradeneeded-event-exception.js'
        'upgrade-transaction-deactivation-timing.js'

Current IndexedDB (and domstringlist) test statuses (vmTimeout = 40000):
  'Pass': 1168, (including 4 domstringlist tests but avoiding exclusions)
  'Fail': 6,
  'Timeout': 5,
  'Not Run': 3,
  'Total tests': 1182 (including 4 domstringlist tests but avoiding exclusions)
@brettz9

This comment has been minimized.

Show comment
Hide comment
@brettz9

brettz9 Apr 14, 2017

Collaborator

For single processes, this issue is now fixed in master and passing a number of formerly failing tests.

However, I think we should keep this issue open as blocked/versionchange events still don't work if someone is running multiple tabs or processes

In the browser, this fix might be implemented via a shared worker but if a browser supports that, it might not be in much need of an IndexedDB shim.

In Node, this fix might be implemented via a shared process or such (ideally via a SharedWorker polyfill which we need for testing anyways).

As mentioned, #273 is another issue relating to multiple processes which ought to be addressed.

Collaborator

brettz9 commented Apr 14, 2017

For single processes, this issue is now fixed in master and passing a number of formerly failing tests.

However, I think we should keep this issue open as blocked/versionchange events still don't work if someone is running multiple tabs or processes

In the browser, this fix might be implemented via a shared worker but if a browser supports that, it might not be in much need of an IndexedDB shim.

In Node, this fix might be implemented via a shared process or such (ideally via a SharedWorker polyfill which we need for testing anyways).

As mentioned, #273 is another issue relating to multiple processes which ought to be addressed.

@brettz9

This comment has been minimized.

Show comment
Hide comment
@brettz9

brettz9 Apr 14, 2017

Collaborator

However, I'll relabel the issue as environment-specific since it probably isn't really practical to polyfill for the browser but it could be and ideally will be done in Node.

Collaborator

brettz9 commented Apr 14, 2017

However, I'll relabel the issue as environment-specific since it probably isn't really practical to polyfill for the browser but it could be and ideally will be done in Node.

@brettz9 brettz9 added Bug-environment support and removed Bug labels Apr 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment