Clarify doc for readset validations (#2647) (#2654)

Clarify that both prior blocks and prior transactions in the same block are considered during readset validation. Signed-off-by: David Enyeart <enyeart@us.ibm.com> (cherry picked from commit 07808a0) Co-authored-by: denyeart <enyeart@us.ibm.com>
hyperledger · Jun 7, 2021 · bd0c432 · bd0c432
1 parent 47fee09
commit bd0c432
Show file tree

Hide file tree

Showing 2 changed files with 10 additions and 8 deletions.
diff --git a/docs/source/glossary.rst b/docs/source/glossary.rst
@@ -148,8 +148,10 @@ Concurrency Control Version Check
 
 Concurrency Control Version Check is a method of keeping ledger state in sync across
 peers on a channel. Peers execute transactions in parallel, and before committing
-to the ledger, peers check whether the state read at the time the transaction was executed
-has been modified. If the data read for the transaction has changed between execution time and
+to the ledger, peers check whether the state read at the time the transaction
+was executed has been modified in a new block that was in-flight at time of execution
+or in a prior transaction in the same block.
+If the data read for the transaction has changed between execution time and
 commit time, then a Concurrency Control Version Check violation has
 occurred, and the transaction is marked as invalid on the ledger and values
 are not updated in the state database.

diff --git a/docs/source/readwrite.rst b/docs/source/readwrite.rst
@@ -73,12 +73,12 @@ read-write set for updating the versions and the values of the affected
 keys.
 
 In the validation phase, a transaction is considered ``valid`` if the
-version of each key present in the read set of the transaction matches
-the version for the same key in the world state - assuming all the
-preceding ``valid`` transactions (including the preceding transactions
-in the same block) are committed (*committed-state*). An additional
-validation is performed if the read-write set also contains one or more
-query-info.
+version of each key present in the read set of the transaction (from time of simulation)
+matches the current version for the same key, taking into consideration
+``valid`` transactions that have been committed to state from new
+blocks since the transaction was simulated, as well as valid preceding transactions
+in the same block. An additional validation is performed if the read-write set
+also contains one or more query-info.
 
 This additional validation should ensure that no key has been
 inserted/deleted/updated in the super range (i.e., union of the ranges)