7

I have a conceptual question. I'm performing async requests to Composer REST and I'm getting message: 'error trying invoke chaincode. Error: Peer has rejected transaction \'552b42fa4d2cfd366ff1b7d01371878f53f7553b44f141187c6db86b75f68906\' with cdoe MVCC_READ_CONFLICT',. I got the same problem when using node-sdk. What is the reason for that? Shouldn't it be possible to submit multiple transactions asynchronously?

Dan Selman
  • 2,237
  • 1
  • 7
  • 17

2 Answers2

8

Hyperledger Fabric uses lock-free optimistic concurrency, with rollback in case of dirty read/writes. You need to avoid key collisions as far as possible and may need to write retry logic on the client side.

The BatchTimeout setting for Fabric can be used to decrease latency (minimise the chance of collisions) at the expense of throughout:

https://github.com/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml#L144

Dan Selman
  • 2,237
  • 1
  • 7
  • 17
  • What do you mean by avoiding key collisions? I generate my own custom asset keys in a loop (incremental), yet I still get this error when trying to submit them ... – Nathan H Sep 04 '17 at 13:28
  • If you have multiple threads updating a given key concurrently then you will hit MVCC read conflict issues, as there is no global lock to prevent concurrent updates to a key. At commit time the version number of the key is checked -- if it is different from that which was previously read then the transaction is rolled back (because the prior read is now dirty). – Dan Selman Sep 06 '17 at 08:02
  • How do you recommend testing for this error code? The error object returned does not have a value for error.code (comes up as undefined). error.message and error.stack are correctly populated. Inspecting the error processing functions in composer-connector-hlfv1/lib/hlfconnection.js shows that none of the error messages which composer delivers have any error codes. – Bob Dill Sep 08 '17 at 14:24
  • 1
    Hi Dan, can you clarify how the BatchTimeout setting can be used to decrease latency? Would you increase or decrease this from the default value of 2s to minimise collisions? – Psymatix Sep 25 '17 at 16:22
  • 1
    I just got this error today while trying to do multiple transactions with the same participant through Composer REST APIs. Are there ways to avoid this? Or do we just have to make all our calls synchronous.. – TheOkayCoder Nov 08 '17 at 00:43
  • The same thing happened to me as well while using node-sdk. – Fthi.a.Abadi Jun 04 '18 at 11:47
6

When you submit a transaction, the peer generates a read and write set. This read/write set is then used when the transaction is committed to the ledger. It contains the name of the variables to be read/written and their version when they were read. If, during the time between set creation and committing, a different transaction was committed and changed the version of the variable, the original transaction will be rejected during committal because the version when read is not the current version.

To address this, you will have to create data and transaction structures which avoid concurrently editing the same key. A sample way to do this is provided in fabric-samples here:

https://github.com/hyperledger/fabric-samples/tree/release/high-throughput

ajp
  • 346
  • 2
  • 4
  • I've tried the chaincode from the above link to no avail. I'm still getting the MVCC_READ_CONFLICT error. Any idea what might cause that? My transaction rate is just 3 Tx/s. With 2 endorsing peers. – Byebye Aug 08 '18 at 11:50