From 67ba3c170016869a583cd51dd958ccdb59cc800b Mon Sep 17 00:00:00 2001 From: Joshua Bell Date: Fri, 28 Jul 2023 10:33:05 -0700 Subject: [PATCH 1/3] Disambiguate "running" for transactions The phrase "a transaction is running" was not normatively defined and confusing given the complex lifecycle of transactions. Introduce a new definition for "live" which covers from a transactions creation until it is finished. Also, rename "running an upgrade transaction" since steps are often invoked with "run" and that could get awkward. Simplify to "upgrade a database". No behavior changes, just normative terminology definitions. Resolves #408. Thanks to @evanstade the issue and suggestions. --- index.bs | 48 ++++++++++++++++++++++++++---------------------- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/index.bs b/index.bs index c8c3c77..25f31bc 100644 --- a/index.bs +++ b/index.bs @@ -474,7 +474,7 @@ A [=/connection=] has an object store set, which is initialized to the set of [=/object stores=] in the associated [=/database=] when the [=/connection=] is created. The contents of the set will remain constant except when an [=/upgrade transaction=] is -running. +[=transaction/live=]. A [=/connection=]'s [=get the parent=] algorithm returns null. @@ -553,13 +553,13 @@ An [=/object store handle=] has an index set, which is initialized to the set of [=/indexes=] that reference the associated [=object-store-handle/object store=] when the [=/object store handle=] is created. The contents of the set will remain constant except when -an [=/upgrade transaction=] is running. +an [=/upgrade transaction=] is [=transaction/live=]. An [=/object store handle=] has a name, which is initialized to the [=object-store/name=] of the associated [=object-store-handle/object store=] when the [=/object store handle=] is created. The name will remain constant except when an [=/upgrade -transaction=] is running. +transaction=] is [=transaction/live=]. @@ -866,7 +866,7 @@ particular [=/index=] within a [=/transaction=]. An [=index handle=] has a name, which is initialized to the [=index/name=] of the associated [=index-handle/index=] when the [=index handle=] is created. The name will remain constant except when -an [=/upgrade transaction=] is running. +an [=/upgrade transaction=] is [=transaction/live=]. @@ -905,7 +905,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 [=transaction/read-only transactions=] can run at the same time even + several [=transaction/read-only transactions=] can be [=transaction/started=] at the same time even if their [=transaction/scopes=] are [=transaction/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. @@ -915,7 +915,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 "{{IDBTransactionMode/readwrite}}" transactions - can't run at the same time if their [=transaction/scopes=] are [=transaction/overlapping=] + can't be [=transaction/started=] at the same time if their [=transaction/scopes=] are [=transaction/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. @@ -1001,7 +1001,7 @@ Transactions are expected to be short lived. This is encouraged by the described below. @@ -1088,6 +1088,8 @@ the case even if the transaction has not yet been requests; however, the implementation must keep track of the [=/requests=] and their order. +A [=/transaction=] is said to be live from when it is [=transaction/created=] until its [=transaction/state=] is set to [=transaction/finished=]. +
To cleanup Indexed Database transactions, run the following steps. @@ -1135,14 +1137,14 @@ The following constraints define when a [=/transaction=] can be [=transaction/st * have [=transaction/overlapping scopes=] with |tx|; and * are not [=transaction/finished=]. -Implementations may impose additional constraints. For example, implementations are not required to run non-[=transaction/overlapping=] read/write transactions in parallel, or may impose limits on the number of running transactions. +Implementations may impose additional constraints. For example, implementations are not required to [=transaction/start=] non-[=transaction/overlapping=] read/write transactions in parallel, or may impose limits on the number of [=transaction/started=] transactions.