1. 03 Feb, 2017 1 commit
    • manish's avatar
      Move Blockstorage code under /fabric/common package · 2a16532c
      manish authored
      https://jira.hyperledger.org/browse/FAB-2022
      
      
      
      This changes introduced by this CR
      - Moves the block storage code from package
      core/ledger/blkstorage to common/ledger/blkstorage
      
      - Splits the ledger_interface.go so as to move common interfaces
      and data type to common/ledger package
      
      - Moves some of the util functions to common/ledger package
      
      - Moves core/ledger/ordererledger package to orderer/ledger/fsledger
      orderer folks can futher rename/refactor this as seems suitable to them
      
      Change-Id: I759e16f00dc2ec9bb62196121083cf48eae76948
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      2a16532c
  2. 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. 18 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. 14 Dec, 2016 1 commit
  6. 06 Dec, 2016 1 commit
    • Balaji Viswanathan's avatar
      FAB-1291: Couch support for doing a savepoint. · 01834832
      Balaji Viswanathan authored
      
      
      Added two functions in couchdb_txmgr.go, recordSavepoint is unexported and called during commit
      go record a savepoint into couch. GetBlockNumFromSavepoint should be used during recovery to
      get the block number associated with the savepoint
      
      Added similar methods to goleveldb txmgr implementation
      
      Added unit test function to xxx_txmgmt_test.go
      
      Change-Id: Id2860232632d29cbe753b2840a625c34e541f2d9
      Signed-off-by: default avatarBalaji Viswanathan <balaji.viswanathan@gmail.com>
      01834832
  7. 04 Dec, 2016 1 commit
    • manish's avatar
      This commit changes the versioning scheme for the keys · 836fdc69
      manish authored
      https://jira.hyperledger.org/browse/FAB-601
      
      
      The height based versioning scheme assigns a version to the key equal to the  height of the transaction that committed it last.
      The benefits include -
      1) We do not need to maintain delete markers for the deleted keys
      2) Makes recovery of state db easier, particularly for couchdb
      3) Enables efficient validation - (in future - does not require validating against latest state has potential for in-memory validation)
      4) Has potential for providing snapshot isolation across sharded data nodes in the future
      
      Change-Id: I5a079c9be5966c349b7bb6c8df6e1a45d9889f1f
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      836fdc69
  8. 18 Nov, 2016 1 commit
  9. 26 Oct, 2016 1 commit
  10. 15 Sep, 2016 1 commit