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
  2. 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
  3. 16 Jan, 2017 1 commit
  4. 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
  5. 08 Jan, 2017 1 commit
  6. 14 Dec, 2016 1 commit