Simplify transaction starting constraints to match reality (#319)

All implementations have a strict ordering of transactions with
overlapping scopes; read-only transactions can run in parallel but
block a later read/write transaction from starting, and the read/write
transactions similarly block later read/write and read-only
transactions.

Tighten up the constraints definition to something precise, and move
the wordy implications into a non-normative aside.

Also, define "overlapping scopes" as a term.

Closes #253

Author: inexorabletash

index.bs

@@ -892,10 +892,9 @@ and data mutation operations.
 All transactions are created through a [=/connection=], which is the
 transaction's <dfn>connection</dfn>.
 
-A [=/transaction=] has a <dfn>scope</dfn> that determines the
-[=/object stores=] with which the transaction may interact. A
-transaction's scope remains fixed for the lifetime of that
-transaction.
+A [=/transaction=] has a <dfn>scope</dfn> which is a [=/set=] of [=/object stores=] that the transaction may interact with. A transaction's scope remains fixed for the lifetime of that transaction.
+
+Two [=/transactions=] have <dfn lt="overlap|overlapping scope">overlapping scope</dfn> if any [=/object store=] is in both transactions' [=transaction/scope=].
 
 A [=/transaction=] has a <dfn>mode</dfn> that determines which types
 of interactions can be performed upon that transaction. The [=transaction/mode=]
@@ -908,7 +907,7 @@ following:
     The transaction is only allowed to read data. No modifications can
     be done by this type of transaction. This has the advantage that
     several [=read-only transactions=] can run at the same time even
-    if their [=transaction/scopes=] are overlapping, i.e. if they are using the
+    if their [=transaction/scopes=] are [=overlapping=], i.e. if they are using the
     same object stores. This type of transaction can be created any
     time once a database has been opened.
 
@@ -917,7 +916,7 @@ following:
     The transaction is allowed to read, modify and delete data from
     existing object stores. However object stores and indexes can't be
     added or removed. Multiple {{"readwrite"}} transactions
-    can't run at the same time if their [=transaction/scopes=] are overlapping
+    can't run at the same time if their [=transaction/scopes=] are [=overlapping=]
     since that would mean that they can modify each other's data in
     the middle of the transaction. This type of transaction can be
     created any time once a database has been opened.
@@ -1115,87 +1114,42 @@ They will return true if any transactions were cleaned up, or false otherwise.
   each [=/transaction=].
 </aside>
 
-<!-- ============================================================ -->
-### Transaction scheduling ### {#transaction-scheduling}
-<!-- ============================================================ -->
-
 An event with type <dfn event>`complete`</dfn> is fired at
 a [=/transaction=] that has successfully [=transaction/committed=].
 
 An event with type <dfn event>`abort`</dfn> is fired at
 a [=/transaction=] that has [=transaction/aborted=].
 
-The following constraints define when a [=/transaction=] can be
-[=transaction/started=]:
+<!-- ============================================================ -->
+### Transaction scheduling ### {#transaction-scheduling}
+<!-- ============================================================ -->
 
-* Any number of [=read-only transactions=] are allowed to run
-    concurrently, even if the transaction's [=transaction/scope=] overlap and
-    include the same [=/object stores=]. As long as a [=read-only
-    transaction=] is running, the data that the implementation returns
-    through [=/requests=] created with that transaction must remain
-    constant. That is, two requests to read the same piece of data
-    must yield the same result both for the case when data is found
-    and the result is that data, and for the case when data is not
-    found and a lack of data is indicated.
+The following constraints define when a [=/transaction=] can be [=transaction/started=]:
 
-    <aside class=note>
-      There are a number of ways that an implementation can ensure
-      this. The implementation could prevent any <a>read/write
-      transaction</a>, whose scope overlaps the scope of the
-      [=read-only transaction=], from starting until the
-      [=read-only transaction=] finishes. Or the implementation
-      could allow the [=read-only transaction=] to see a snapshot
-      of the contents of the [=/object stores=] which is taken when
-      the [=read-only transaction=] started.
-    </aside>
+* A [=read-only transactions=] |tx| can [=transaction/start=] when there are no <a>read/write transactions</a> which:
+    * Were [=transaction/created=] before |tx|; and
+    * have [=overlapping scopes=] with |tx|; and
+    * are not [=transaction/finished=].
+* A <a>read/write transaction</a> |tx| can [=transaction/start=] when there are no [=/transactions=] which:
+    * Were [=transaction/created=] before |tx|; and
+    * have [=overlapping scopes=] with |tx|; and
+    * are not [=transaction/finished=].
 
-* Similarly, implementations must ensure that a <a>read/write
-    transaction</a> is only affected by changes to [=/object
-    stores=] that are made using the transaction itself. For
-    example, the implementation must ensure that another transaction
-    does not modify the contents of [=/object stores=] in the
-    <a>read/write transaction</a>'s [=transaction/scope=]. The implementation
-    must also ensure that if the <a>read/write transaction</a>
-    completes successfully, the changes written to [=/object
-    stores=] using the transaction can be committed to the
-    [=database=] without merge conflicts. An implementation must
-    not abort a transaction due to merge conflicts.
-
-* If multiple <a>read/write transactions</a> are attempting to access
-    the same object store (i.e. if they have overlapping [=transaction/scope=]),
-    the transaction that was [=transaction/created=] first must be the transaction
-    which gets access to the object store first. Due to the
-    requirements in the previous paragraph, this also means that it is
-    the only transaction which has access to the object store until
-    the transaction is [=transaction/finished=].
-
-* Any transaction [=transaction/created=] after a <a>read/write transaction</a>
-    must see the changes written by the <a>read/write transaction</a>.
-    So if a <a>read/write transaction</a>, A, is created, and later
-    another transaction B, is created, and the two transactions have
-    overlapping [=transaction/scopes=], then B must see any changes made to any
-    [=/object stores=] that are part of that overlapping [=transaction/scope=].
-    Due to the requirements in the previous paragraph, this also means
-    that the B transaction does not have access to any [=/object
-    stores=] in that overlapping [=transaction/scope=] until the A transaction is
-    [=transaction/finished=].
+Implementations may impose additional constraints. For example, implementations are not required to run non-[=overlapping=] <a>read/write transactions</a> in parallel, or may impose limits on the number of running transactions.
 
-    <aside class=note>
-      Generally speaking, the above requirements mean that any
-      transaction which has an overlapping scope with a <a>read/write
-      transaction</a> and which was created after that <a>read/write
-      transaction</a>, can't run in parallel with that <a>read/write
-      transaction</a>.
-    </aside>
+<aside class=note>
 
-* User agents must ensure a reasonable level of fairness across
-    transactions to prevent starvation. For example, if multiple
-    [=read-only transactions=] are started one after another the
-    implementation must not indefinitely prevent a pending
-    <a>read/write transaction</a> from [=transaction/starting=].
+  These constraints imply the following:
 
-</div>
+  * Any number of [=read-only transactions=] are allowed to run concurrently, even if they have [=overlapping scopes=].
+  * As long as a [=read-only transaction=] is running, the data that the implementation returns through [=/requests=] created with that transaction remains constant. That is, two requests to read the same piece of data yield the same result both for the case when data is found and the result is that data, and for the case when data is not found and a lack of data is indicated.
+  * A <a>read/write transaction</a> is only affected by changes to [=/object stores=] that are made using the transaction itself. The implementation ensures that another transaction does not modify the contents of [=/object stores=] in the <a>read/write transaction</a>'s [=transaction/scope=]. The implementation also ensures that if the <a>read/write transaction</a> completes successfully, the changes written to [=/object stores=] using the transaction can be committed to the [=database=] without merge conflicts.
+  * If multiple <a>read/write transactions</a> are attempting to access the same object store (i.e. if they have [=overlapping scopes=]), the transaction that was [=transaction/created=] first is the transaction which gets access to the object store first, and it is the only transaction which has access to the object store until the transaction is [=transaction/finished=].
+  * Any transaction [=transaction/created=] after a <a>read/write transaction</a> sees the changes written by the <a>read/write transaction</a>. For example, if a <a>read/write transaction</a> A, is created, and later another transaction B, is created, and the two transactions have [=overlapping scopes=], then transaction B sees any changes made to any [=/object stores=] that are part of that [=overlapping scope=]. This also means that transaction B does not have access to any [=/object stores=] in that overlapping [=transaction/scope=] until transaction A is [=transaction/finished=].
+
+</aside>
 
+</div>
 
 <!-- ============================================================ -->
 ### Upgrade transactions ### {#upgrade-transaction-construct}
@@ -6864,6 +6818,7 @@ For the revision history of the second edition, see [that document's Revision Hi
 * Restrict array keys to [=/Array exotic objects=] (i.e. disallow proxies). ([Issue #309](https://github.com/w3c/IndexedDB/issues/309))
 * Transactions are now temporarily made inactive during clone operations.
 * Added {{IDBTransactionOptions/durability}} option and {{IDBTransaction/durability}} attribute. ([Issue #50](https://github.com/w3c/IndexedDB/issues/50))
+* Specified [[#transaction-scheduling]] more precisely and disallow starting read/write transactions while read-only transactions with overlapping scope are running. ([Issue #253](https://github.com/w3c/IndexedDB/issues/253))
 
 <!-- ============================================================ -->
 # Acknowledgements # {#acknowledgements}