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?
相关问题
- How to add a new Orderer Organization to existing
- chaincode in hyperledger composer vs chaincode in
- Hyperledger fabcar sample fabric showing connect f
- OCI runtime exec failed: exec failed: container_li
- User level restriction in hyperledger fabric 1.0
相关文章
- When I generate MSP for some organization, I can c
- Does Composer needs an already built Fabric networ
- Hyperledger transaction verification
- Hyperledger Fabric - Error while Instantiating cha
- Hyperledger fabric's ChannelCreationPolicy
- what kind of peer types does hyperledger have?
- How to retrieve user information from recent versi
- hyperledger fabric first_network example create ch
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
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