2

我在 fabric-sdk-go 中使用 client.channel.Execute API 来调用链代码中的分类帐更新 Txs。

我知道我用于分类帐更新的链码是正确的，因为从 cli 容器命令行运行时调用 Tx 始终运行良好。

很少有随机地，分类帐更新在作为来自 POSTMAN 的 REST API 调用执行时没有反映，如下所示。在这些情况下，响应代码为 200，带有正确的响应负载，表明链码运行成功。

`

chaincodeID := "hcc"
fcn := "GiftToken"
args := [][]byte{
    []byte(reqBody.TokenID),
    []byte(reqBody.GiftToUserID),
    []byte(GiftTokenCountAsString),
}

setup := lib.GetFabricSetup()

transientDataMap := make(map[string][]byte)
transientDataMap["result"] = []byte("Transient data in GiftToken invoke")

response, err := setup.Client.Execute(channel.Request{ChaincodeID: chaincodeID, Fcn: fcn, Args: args, TransientMap: transientDataMap})

我在 docker 容器中运行 Fabric 1.4.4 映像。我的网络有 1 个组织和 4 个对等节点。

肯定缺少导致这种行为的某些方面。提前致谢。

4

1 回答 1

1

所有对等方都需要时间来同步他们的块。一旦对等方收到这些块，他们就会更新他们的世界状态，因此您可以通过查询查看您的更改。

当您查询“刚刚执行”的交易时，您可能会遇到其他同行之一。如果您想要立即得到结果，请确保您正在查询实际执行交易的同一个对等方。您可以尝试延迟一些时间来查看其他对等方以及获得阻止。

您在 CLI 上立即看到更改的原因是关于客户端实现的方式。在 CLI 命令执行时，您明确指定对等方。因此事务在一个对等点上执行并在同一个对等点上查询（没有问题）。您可以在执行事务后（通过 CLI）立即查询（通过 CLI）另一个组织的对等方来证明这种行为。

但是对于您的客户端，可能由于您没有明确指定对等点，您的客户端 SDK 使用对等点的发现服务并为您在网络中找到对等点并使用它。

由于这个原因，当形成“AND(org1, org2)”这样的背书策略时，客户端SDK实际上会查询2个peer（每个org一个）并比较结果。

于 2020-05-28T10:23:09.557 回答