HLF Chaincode - docker peer [MVCC_READ_CONFLICT]

64 Views Asked by At

I have a Data61BPMNtoChaincode Project on a ubuntu vm. (https://github.com/leoaction/Data61BPMNtoChaincode/tree/master)

For starting a client, NodeJS is used as a server which sends multiple requests like installChaincode and Deploying chaincode to the network.

When everything is running one can issue a request by sending a transaction to the server which performs either query or invoke -orderer requests to the running peers which runs isolated in a docker container.

In BPMN there is this possibility to build a process with a parallel Block, so 2 or more Activities will be "performed" in parallel.

Looks like this: BPMN parallel Block

So, it could be that the requests are pretty fast and so there is a read on a state which i guess is the old State and so there comes the error: MVCC Read conflict on the peer which is running on a docker container. So Peer A updated a variable with value 1, but the next request which is somehow concurrently trying to read the data just reads the old value 0.

If i introduce a sleep on client side for 3 seconds than it works. But i do not want to have sleeps in production thats why i want to catch this error and send the request again.

Now my question is how can i catch this error in the chaincode in order to propagate it back to the nodeJS Server so that i can send the request again. I think this must be done in the chaincode?

Running peers: running peers

Log of peer: log of peer

Thanks for any help.

2

There are 2 best solutions below

0
sebi On BEST ANSWER

I have solved the issue by adding --waitForEvent flag to the invoke orderer request. This seems to wait until the first transaction has been committed on so on the second the value is updated.

Solution: cli peer chaincode invoke --waitForEvent -o orderer ...

Thanks for helping.

3
bestbeforetoday On

You cannot catch this condition in your smart contract. The error occurs later in the transaction flow during validation, after the transaction has been recorded in a block on the blockchain.

This workshop material might help clarify the transaction flow as it relates to the client application:

https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/01-FabricGateway.md

Your Node server (which in this case is interacting with the Fabric network as a client application), identifies the failure when it obtains the transaction commit status and receives an MVCC_READ_CONFLICT validation code. The failed transaction is recorded on the blockchain and any subsequent transaction using the same transaction ID will fail due to a duplicate transaction ID. Your client application needs to attempt the entire transaction submit process again with the same arguments and a new transaction ID.

This documentation from the same workshop material linked above (and the accompanying sample client application code) provide a simple example of identifying the failure reason and retrying the transaction submit:

https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/03-ApplicationOverview.md#retry-of-transaction-submit