HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

huangapple go评论62阅读模式
英文:

HLF Chaincode - docker peer [MVCC_READ_CONFLICT]

问题

我有一个在Ubuntu虚拟机上的Data61BPMNtoChaincode项目(https://github.com/leoaction/Data61BPMNtoChaincode/tree/master)。

要启动客户端,使用NodeJS作为服务器,发送多个请求,如installChaincode和部署chaincode到网络。

当一切正常运行时,可以通过向服务器发送交易来发出请求,服务器执行查询或调用-在运行在docker容器中的运行peer上的orderer请求。

在BPMN中,有可能构建一个带有并行块的流程,因此2个或多个活动将并行“执行”。

看起来像这样:HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

因此,可能请求非常快,因此会对我猜是旧状态的状态进行读取,所以出现了错误:运行在docker容器中的peer上的MVCC读取冲突。

所以Peer A用值1更新了一个变量,但下一个请求,某种并发地尝试读取数据,只读取旧值0。

如果我在客户端端引入3秒的睡眠,那么它就可以工作。但我不想在生产中使用睡眠,所以我想捕获这个错误并重新发送请求。

现在我的问题是,我如何在chaincode中捕获此错误,以便将其传播回nodeJS服务器,以便我可以重新发送请求。我认为这必须在chaincode中完成?

运行的peer:HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

peer的日志:HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

感谢任何帮助。

英文:

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: HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

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: HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

Log of peer: HLF Chaincode – docker peer [MVCC_READ_CONFLICT]

Thanks for any help.

答案1

得分: 0

你无法在智能合约中捕获这个条件。错误会在事务流程中的验证阶段后发生,此时事务已记录在区块链的区块中。

这个研讨会材料可能有助于澄清与客户端应用程序相关的事务流程:
https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/01-FabricGateway.md

您的Node服务器(在这种情况下充当与Fabric网络交互的客户端应用程序)在获取事务提交状态并收到MVCC_READ_CONFLICT验证代码时识别失败。失败的事务已记录在区块链上,任何后续使用相同事务ID的事务都会因重复事务ID而失败。您的客户端应用程序需要使用相同参数和新的事务ID再次尝试整个事务提交过程。

来自上述研讨会材料链接的此文档(以及附带的示例客户端应用程序代码)提供了识别失败原因并重试事务提交的简单示例:
https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/03-ApplicationOverview.md#retry-of-transaction-submit

英文:

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

答案2

得分: 0

我已经通过向调用订购方请求添加--waitForEvent标志来解决了这个问题。这似乎会等待第一笔交易已经提交,然后在第二笔上更新值。

解决方案:cli peer chaincode invoke --waitForEvent -o orderer ...

感谢您的帮助。

英文:

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.

huangapple
  • 本文由 发表于 2023年6月21日 22:57:16
  • 转载请务必保留本文链接:https://go.coder-hub.com/76524653.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定