Re: [w3c/IndexedDB] Specify timing of transaction deactivation more precisely (#87)

Thanks for chiming in, everyone!

> Hmm, if I read chromium's source code right, it uses EndOfScopeTask (which is microtask scheduling) for transaction creation for example,
> but then firing success event uses different setup, since it explicitly sets the active flags.

That's the difference between case 1 and case 2 in the original post. 

=== Case 1 ===

EndOfScopeTask handles case 1; this was introduced before microtasks (though more explicitly IDB-specific prior to refactors); it's only used by IDB. That it's bolted on to microtask processing is just how it evolved in our code base. Hence this tracking bug. :)

Here's Blink's behavior in pseudocode that handles case 1 (the `transaction()` call)

```
run_javascript_callback:
  execute_callback;
  execute_microtasks;
  execute_end_of_scope_tasks;
```

... where any call to `transaction()` would register an end_of_scope task to deactivate it. (Note that "task" here is just a C++ callback, not a spec task.)

This explains the behavior seen in the example by @bevis-tseng - each event callback invocation is a separate run of these steps, so the transaction created by `transaction()` in the first listener's callback is deactivated before the second listener's callback runs.

Note that it is web-observable that this happens after microtasks are run, and that any `transaction()` call in the microtask queue would end up adding additional end-of-scope tasks to the same list. I suspect it would be web-compatible to make changes here if we needed to reduce the magic in the platform here.

=== Case 2 ===

In Blink, the logic that handles activating/deactivating transactions on event dispatches is higher up in the stack. In pseuducode:

```
dispatch_idb_event:
  event = create_event;
  targets = [request, transaction, database];
  transaction.active = true;
  dispatch_event(event, targets);
  transaction.active = false;
```

... where the dispatch_event step encapsulates all of the normal event propagation (or not) and listeners.  Implicitly this runs the steps up above for invoking JS callbacks, so microtasks get run within this as well. I believe this is the bit @smaug---- is referring to as aligning soon in Moz?

...

FWIW, I think the spec describes case 2 sufficiently (but feedback welcome). I believe case 1 is still hand-wavy and probably require propagating changes to HTML (per @annevk) once we agree on how to describe the behavior and what's necessary for compat, etc. But I'm far from certain.

Maybe other implementers could chime in with what they're doing here and we can converge on behavior and then come up with a decent way to describe it?

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