Skip to content
GitLab
  1. 24 Jan, 2017 1 commit
    • manish's avatar
      Detect phantom items during validation · 16372176
      manish authored 
      https://jira.hyperledger.org/browse/FAB-1668



Phantom reads problem:
-----------------------------
If a transaction executes a key range query (say key_1 - key_n) leveldb
serves all the keys in the given range in sorted order of keys.
Between simulation and validation of a transaction, some other transaction
may insert one or more keys in this range. Now, this change cannot
be detected by merely checking the versions of the keys present in
the read-set of the transaction.
(though, this check can detect updates and deletes).

A serializable isolation level does not permit phantom reads.

Situations where the phantom reads may not be acceptable:
-----------------------------
 - A chaincode may take a decision based on aggregates of the results of
the range query such as min/max/avg/sum etc. This would be affected
if a new entry gets added to the range query results.

 - A chaincode may want to change all the marbles
owned by a specific user to blue in a tran `t1`. The chaincode may do so
by performing a range query to get all the marbles for the user and
change their color to blue. Now, if a new white marble get added to
the user's assets by an another transaction `t2`,
`t1` should be marked as invalid.

Solution in this change-set:
-----------------------------
For solving this, we can capture the details of the range query
(the query and it's results) during the simulation time and
re-execute the query during validation time and compare the results.
If the results (keys and versions) are still the same,
we can safely commit the transaction.

This changes set introduces
 - Structures for capturing the range query details in rwset
 - Detection of phantom items (insertion/deletion)
   that affect the results of the range query during validation
 - Mark the transactions that are affected by the phantom items
   as invalid to ensure serializability in the presence of range queries

Change-Id: I909841a0234c37795ad7a4ffcca8a9ebd9c9f994
Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      16372176
  3. 17 Jan, 2017 1 commit
    • manish's avatar
      SingleLevelDB for block index · 8cdd0f4d
      manish authored 
      https://jira.hyperledger.org/browse/FAB-1664



This changeset:
- Renames package ledger/util/db to ledger/util/leveldbhelper
- Implements a leveldb provider
  (that enables using same leveldb instance as a multiple logical dbs)
  in util package for being able to reuse across statedb, index,
  and later for historydb
- Implements a provider as a single point of invocation
  for managing multiple block storage
- Uses a single leveldb instance for block storage index
- Makes the structures other than providers as private
  to their respective packages

Change-Id: I5f0b3b9aa8ef3ac1ccdce4f3c6fa6d842b5318c1
Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      8cdd0f4d
  5. 16 Jan, 2017 1 commit
  7. 15 Jan, 2017 1 commit
    • denyeart's avatar
      FAB-1505 and FAB-1337 Refactor CouchDB code · 9df7b0ea
      denyeart authored 
      

FAB-1505 refactors CouchDB code to be aligned with LevelDB structure.
FAB-1337 applies all ledger tests written for LevelDB against CouchDB.

In order to test the CouchDB refactor,
had to implement FAB-1337 in same changeset to test.

Like most refactors, this changeset touches a lot of files and code,
since it is not feasible to do a partial refactor.

Tests related to versioning and deleting have been commented out,
these will be re-enabled in subsequent changeset when CouchDB
has the support, in order to keep this changeset size more reasonable.

Change-Id: I0d2d6cca89bd0252f6e84317457a9140b3a0d7a5
Signed-off-by: default avatardenyeart <enyeart@us.ibm.com>
      9df7b0ea
  9. 08 Jan, 2017 1 commit
  11. 14 Dec, 2016 1 commit