CODEWITHSUNDEEP
hyperledger-fabrichyperledger-composer
Tara
Tara

Reputation: 549

hyperledger PHANTOM_READ_CONFLICT .vs. MVCC_READ_CONFLICT

I used to get MVCC_READ_CONFLICT error and know what that means, but recently I upgrade it to enterprise version and starts getting PHANTOM_READ_CONFLICT error insted, what does PHANTOM_READ_CONFLICT mean? Did try to google it but was not able to find anything about it.

Also how is it different from MVCC_READ_CONFLICT, I know how to handle MVCC_READ_CONFLICT but not PHANTOM_READ_CONFLICT because I don't know what it means.

Upvotes: 0

Views: 1592

Answers (1)

yacovm
yacovm

Reputation: 5140

Phantom reads are when you have a range query in your chaincode, and at time of commit - the range query is re-run and the result is different than the result that you had during the chaincode execution.

Imagine you do a range query and then count the number of elements and write the result to a key "count". It may be that after the execution of the chaincode and before the commit - someone inserted a new element. Without a range query re-validation during commit time - the transaction would have written the wrong value of count.

From the official documentation:

This additional validation should ensure that no key has been inserted/deleted/updated in the super range (i.e., union of the ranges) of the results captured in the query-info(s). In other words, if we re-execute any of the range queries (that the transaction performed during simulation) during validation on the committed-state, it should yield the same results that were observed by the transaction at the time of simulation. This check ensures that if a transaction observes phantom items during commit, the transaction should be marked as invalid. Note that the this phantom protection is limited to range queries (i.e., GetStateByRange function in the chaincode) and not yet implemented for other queries (i.e., GetQueryResult function in the chaincode). Other queries are at risk of phantoms, and should therefore only be used in read-only transactions that are not submitted to ordering, unless the application can guarantee the stability of the result set between simulation and validation/commit time.

Upvotes: 5

Related Questions